Version 5.0 of CP SDK for iOS Released
Wait, version 5.0???
Yes, version 5.0.
We are very excited to publish the latest release of the SAP Cloud Platform SDK for iOS, which includes Mac Catalyst support and Module Stability. These capabilities are super-cool, and contain internal enhancements foundational to the next generation of the SDK, so this is a big deal. But, there is a critical tradeoff in OS version support that needed to be made, which is why we are incrementing the major version number. We cannot support iOS 12 on this code line. So, SDK version 5.0 is iOS 13+, and we will execute on this OS support program:
- Version 5.0 will support only iOS 13 and higher, and Mac Catalyst
- Version 4.0.x will continue to support iOS 12&13
- The 4.x code line will be maintained and patched for new versions of the Swift compiler as necessary
- When iOS 14 is publicly available in September 2020, support for iOS 12 will be dropped, per our standard n-1 iOS support model
- A few new features will be down-ported from 5.0 code line, driven primarily by requirements from the MDK
Now, you might be thinking… if we’re only supporting iOS 13+, this means we can start to use SwiftUI and Combine, right? ? yes indeed … more to come soon 😉
Assistant App Generation
The SAP Cloud Platform SDK for iOS Assistant has been updated to support the option to generate projects with Mac Catalyst support. If you don’t enable this this during generation, you can always add the capability manually in the Target “General > Deployment Info” settings.
There are three key updates for the newly-generated projects:
- The generator has been updated to support multiple destinations, for both the proxy classes, and in the boilerplate entity viewer UI.
- The Frameworks now contains xcframework archives, instead of architecture-specific frameworks.
- The app parameters (CPMS appID, and Destinations) are moved to a new file named AppParameters.plist. These are independent of the legacy connection settings, which in the generated apps continue to be included in the ConfigurationProvider.plist file.
For iPhone Simulator and iPhone targets, there are no changes to the prerequisites for running: you just need to select a Developer Team the Target “Signing & Capabilities > Signing” settings in order to run on device.
For Mac targets, there are three critical new prerequisites:
- You need to add the Keychain Sharing capability. This is to enable the read/write to the Mac system keychain. No actual *sharing* is required or expected–we just want the rights to access the keychain as we do on iOS devices. I’ve seen comments that simply adding the capability is sufficient, and you don’t need to actually add a group. I have better success when adding a group.
- You need to specify a Signing Certificate. The default ‘Development’ and ‘Run Locally’ options are insufficient. The easy way to do this, is after having added Keychain Sharing, add an App Group. This will trigger the signing certificate selection procedure.The reason(s) for this second requirement are the intersection of a Venn diagram. We need access to the Keychain, so the Hardened Runtime checks are activated by the system to validate the accessing binary signatures. In theory, the Hardened Runtime > Disable Library Validation setting ought to circumvent this, but this does not seem to be the case in Xcode 11.3.1.On completing #1 and #2, your Target’s Signing & Capabilities tab should appear as follows under the macOS platform section:
- Lastly, we need to add a script to the Build Phases, which signs the embedded SDK frameworks with your Signing Certificate. (Shouldn’t it be sufficient to select ‘Embed & Sign’ in the link section? Probably, but not in Xcode 11.3.1).The generated app includes this Build Phase by default, entitled “Codesign Binaries”, and it executes a script located at ./scripts/codesign.py.If you are linking the xcframeworks into an existing app, you can add this Build Phase manually, before the “Compile Sources” step. You can export the latest version of the script from the Assistant menu.
When successfully configured, it should appear as follows:
When Steps #1-3 are complete, you’re ready to build and run normally to a Mac target!
Note: SAPML framework is delivered as an xcframework, but does not yet support Catalyst.
One of the real operational challenges thus far in delivering the SDK as binary frameworks has been the lack of module interface compatibility across Swift compiler versions. This has meant that for nearly every Xcode release, a new patch has needed to be produced and released on SMP and the Developer/Trials site. This is why each SDK release <=4.x specifies the Xcode version with which it was built.
With Swift 5.1, Module Stability was introduced, which finally allows forward compatibility of the SDK binaries to future versions of Xcode and the Swift compiler. This should allow developers to immediately update to new versions of Xcode when they are released, and continue to use their existing version of the SDK binaries.
There are always risks of breaking changes related to new tools or iOS versions. SAP always recommends validating new component versions in your landscape, before going into production.
Module Stability on Apple platforms has a dependency on objc runtime features in iOS 13. Therefore, it will be supported in version 5.0 and higher of the SAP SDK. Version 4.x will not support the feature, and new patches to the SAP SDK may be necessary to support new Swift compiler versions for the 4.x code line.
Other New Features
- SFSymbols: the FUIIconLibrary images in the SAPFiori framework have been updated to adopt the SFSymbols image capabilities. This enables the images to grow/shrink with the user’s Dynamic Type font settings.
- Long-press to copy capability has been introduced to the FUIKPIHeader, FUIObjectHeader, FUITextKitView (internal), and FUILabel components. On select, the Copy menu is displayed, and the user may tap to copy the text of the component to the standard pasteboard.
- Hierarchy Picker: A variant of the FUIListPicker table view has been added for integration with the FUIHierarchyView.
- Restore Behavior: A new SAPFioriFlows flag isAllowingOfflineRestore has been introduced to configure auth failure behavior for returning users launching offline-enabled apps without network connectivity.
- Grid item mapping: mapping API is introduced to map FUIObjectView icons to FUIGridTableViewCell columns.
As always, please report issues to component MOB-SDK-IOS.
For developers encountering signing issues related to "Ambiguous Apple Developer Identity", see blog here: https://blogs.sap.com/2020/03/09/sdk-5.0-handling-ambiguous-apple-developer-identity/.