The AirWatch team recently released a completely refreshed and re-architected SDK for iOS using the new iOS Swift programming language.

Quote:

As part of the release, we wanted to make sure we’re soliciting feedback from the folks in our development community to make sure we’re taking into account any and all considerations about the adoption of the new SDK along with any questions people may have.

That’s what our second Slack town hall today was all about.

Present in our #workspaceone channel to answer questions were Lucas Chen and Reeves Kissel. Lucas is the product manager for the SDK. And Reeves is one of the members on their iOS engineering team. Lucas and Reeves are both based out of Atlanta, GA.

Please find a cleaned-up transcript of our conversation below. Any additional questions, just post a comment or join the conversation on the #workspaceone channel. The AirWatch team is very responsive!

In case you haven’t joined the VMware {code} program yet, simply register, and you’ll receive your personal Slack invite immediately.

Thanks once again to everyone who was able to join us. We appreciate all the feedback and engagement!

Summary of questions & answers

Q: What are some of the main benefits of the new Swift SDK?
A: There are many great benefits of the Swift SDK. One is the improvement in user experience, i.e., much less flipping to agent or container. Also, the Swift SDK brings with it Workspace One compatibility, reduced integration time, and from our developer perspective the new Swift SDK is much more stable and maintainable allowing us to provide you with a higher quality product!

Q: How long did the rearchitecting project take, beginning to end (roughly)?
A: Great question! The complete re-design and re-write of the SDK in swift took about 9 months to achieve parity with the Obj-c SDK and then another 3 months for the new improvements.

Q: If I’m already using the Objective-C SDK, what do I need to do or know to migrate to Swift?
A: The good news is that migration is extremely easy and very similar to a regular SDK upgrade that you would be doing between two version of the OBJ-C SDK. The APIs remain the same if you are calling from OBJ-C. They are simpler if you are calling these APIs from swift which should make things much cleaner.

We have also made sure to document a step-by-step guide for everyone to be able to following along with while migrating their project from OBJ-C SDK to Swift SDK.

You can learn more at this link. There is also a PDF inside the DMG file the SDK is shipped in.

Another important step to take is to ensure your SDK app(s) have keychain sharing enabled. As Reeves mentioned earlier, one of the key highlights in the Swift SDK is the reduced flipping between apps…the way we’ve accomplished that is through the use of the keychain for app to app communication. That’s why it’s going to be crucial in the new Swift SDK integration that your apps have keychain sharing enabled…if it’s not shared then the app can still function and all but you just lose out on some functionality such as SSO.

Q: What version of Swift is this written in and is there anything I need to do to incorporate into a Swift 4 project?
A: The 17.6 release of the Swift SDK will have both a 3.1 and 3.2 version of the SDK so your Swift 4 project will be compatible with the 3.2 version. Future releases after 17.6 will be swift 4 only. However, we are at the mercy of Apple if Swift 5 comes along in the future.

The current version of the Swift SDK is 17.5, we expect 17.6 to be released within the next 2-3 weeks.

Q: What version of the console do we need to be on in order to support these features? At least 9.0? Does it matter?
A: Great question! It does matter. The Swift SDK requires the console to be on version 9.1.1 or higher.

Q: Are you all supporting the latest version of Swift?
A: Yes, in the 17.6 DMG we will be providing a Swift 3.1 version of the SDK and a Swift 3.2 version of the SDK which is compatible with Swift 4.0. All releases after 17.6 will only include the Swift 4 version of the SDK.

Q: For keychain sharing: this is only useful if we’re shipping multiple SDK-enabled apps, right?
A: That’s correct.

Q: In the objective C version of the SDK, we have to enable ATS settings for using 404.air-watch.com which is a security flag internally for our security scans through HP Fortify. Is that ATS setting something that remains with the Swift version of the SDK?
A: You don’t need to do that anymore, Enabling ATS was supposed to be a workaround for a larger defect (involving a Tunnel Proxy HTTPS reachability check not working correctly) we had a while back but we’ve since then patched the root issue.

Q: What about Xamarin?
A: We also have a Xamarin component for our SDK. We have plans to migrate our Xamarin component to use Swift SDK in the near future as well.

For more, check this link.

Q: In the past, when we’ve upgraded we experienced some issues with jumping versions. Have you all done any testing in regards to jumping versions and if so what were your findings?
A: The migration path from Obj-C to Swift was part of our migration path. Although it depends on how old your Obj-C SDK version is. If you’re utilizing the 5.9.x versions of the Obj-C SDK you should be good.

As long as you follow our guide and go through the migration steps, you will be fine. I think the keychain migration may be the trickiest part, but that really just depends on how things are setup in your apps today.

We have run through many possible scenarios and have documented the steps needed to set up keychain settings and have even documented the 4 most common issues you may run in to and how to resolve those issues.

If you check out our keychain enablements page on the documentation you should see a general overview as well as two other pages 1 for troubleshooting and 1 for basic enablement.

Q: Does the Swift SDK take advantage of the Apteligent integrations?
A: Currently, the Apteligent SDK is still a separate offering and not technically coupled with the Workspace ONE (AirWatch) SDK. Although we have some really neat integration projects on our roadmap that will allow you to get visibility into analytics regarding SDK apps (both written by you as well AirWatch productivity apps) being used by your end users. And of course, you can always integrate an app that includes both the Apteligent SDK in addition to the Workspace ONE SDK. There shouldn’t be any conflicts.

Q: What about SDK profiles? Any changes there? Anything new that has to be enabled?
A: No changes have been made to the SDK profiles, I think the main considerations are around how passcode sharing and SSO work between SDK apps now with the new keychain sharing approach. Not necessarily a direct change to the SDK profile, but worth knowing in case it applies to you.

There’s a nice blurb about it here in this KB article: Preparing for the New iOS Swift SDK

Although take that KB article with a grain of salt since that article was written during the release of 17.5 so some of the information about Swift versions will be out of date very soon once we release 17.6.

Q: What are your plans regarding the Obj-C SDK?
A: We will continue to support the Obj-C SDK until at least the end of 2018. The support will be limited to only bug fixes and defects and we don’t expect to have iOS 12 support with the Obj-C SDK. All new feature development will only be in the new Swift SDK. We’ll publish an official announcement soon with more exact details and dates.

With that being said, we want everyone to be successful in their adoption of the new Swift SDK so please don’t hesitate to reach out if you have any questions.

Q: What’s usually the best way to reach the AirWatch team?
A: Please find us on Slack.