Skip to Content
Technical Articles

Developing a native iOS SDK

This is a part of a blog series. In this blog I am describing how we build a iOS application to replace the old cordova based solution. This will describe how to build a state of the art mobile solutions today with little efforts and in a short time.

SAP and Apple announced a partnership in May 2016 to enhance the mobile experience of enterprise customers. Statistics state that iOS devices are used by 98% of Fortune 500 companies, and SAP systems are used in 76% of global business transactions. These facts motivated both companies to cooperate closely with each other to bring iOS and the SAP Cloud Platform (SCP) world together by delivering SCP SDK for iOS (Apple 2016©; SAP 2019© ). This SDK combines SCP power and features, with the iOS capabilities to offer potentialities of developing enterprise-level mobile applications taking advantage of accessing live data anytime. Apple describes that “the SAP Cloud Platform SDK for iOS lets developers build, extend, and run iOS apps, powered by the SAP Cloud Platform and enterprise backend data” (Apple 2017).

Figure 1: iOS Applications’ Components by using SCP SDK

SAP Cloud Platform SDK for iOS gives access to enterprise data and provides a set of controls with the SAP Fiori Design. The SDK is written in swift programming language. The iOS SDK and mobile services support offline and online access to enterprise data.

The first big key feature of the SDK is the iOS Assistant, a Mac-based application to set up and connect a new iOS project to SCP. The iOS Assistant can generate Swift proxy classes according to the corresponding Odata API of the backend. This enables developers to generate fully typed client model with a few clicks, giving them access to online or offline data. Besides the secure access to the data the SDK also provides easy access to other key enterprise features like logging, tracing,  authentication and Fiori Design UI Controls.  Fiori for iOS design language provides additional UI components with iOS design principals using Apple’s Human Interface Guidelines. These additional UI elements are reusable controls, UI patterns, views, and templates that accelerate the development as the developer does not have to reinvent the commonly used enterprise controls.

Development

This section discusses the process of creating a native iOS application based on the existing backend services of EventApp. In addition to the implementation of an UIView- Controller, the procedures of initiating the iOS application are explained and supported by screenshots to enhance understanding.

After installing the SCP SDK for iOS on a Mac machine, the SAP Cloud Platform SDK for iOS Assistant is accessible through the application folder or Launchpad.

Figure 2: iOS SDK Assistant

For this scenario there is already a backend configured which will be reuse so one can select the “Reuse Existing Application“.

Figure 3: iOS Applications’ Server-side Configuration

In the next step, the iOS Assistant displays the list of linked Odata services to the developer’s account, allowing them to choose one or multiple data destinations and gives the functionality to add a new Odata service by providing the required details.

In the Feature step (Figure 4), different features can be enabled for the iOS project.

Figure 4: iOS Applications’ Features

The next step configures the XCode project’s name and bundle ID.

Step six provides the possibility to feed an OData metadata XML file to use custom proxy generation instead of the metadata retrieved from the backend. The last step enables the generation of sample Master-Detail screens as the application’s UI.

Within a few seconds after pressing the Finish button, the iOS Assistant generates an iOS project in Swift language and opens it in XCode. File and folder structure of the iOS project without generating the Master-Detail UI.

 

The generated Proxy Classes folder contains classes for every entity set and function defined in the connected OData service. The Onboarding folder has several files to manage authentication, offline data store related processes like initialization and sync.

Generating a Master-Detail UI by iOS Assistant and modifying it is a quick start to verify that the right data is now available on the mobile device.

For this project the UI implementation will be done from the ground up. Following the design prototype, several UI views have to be created and connected to enable the in-app navigation. These UI views were implemented in the main storyboard of the iOS project and, by applying the Model–View–Controller (MVC) design pattern, a ViewController is developed and assigned to each view.

Figure 5: Storyboard of our iOS application

The EventList UIView is implemented to provide a similar development process as done for the MDK client. A simple UITableView is added to the main storyboard of this page and connected to a ViewController class to add and adjust different UI elements and functionalities.

For this purpose, the EventListViewController class is created inheriting the UIView-Controller class. This class contains an array to store event objects and is created with the type of Event class, which is an auto-generated proxy class. There are two approaches to populate this array, using offline or online queries In this view the data is loaded from the offline OData store. If the offline DB has synced successfully, event objects are received from it. Otherwise, an online query retrieves the events.

private func requestEntities(completionHandler: @escaping (Error?) -> Void) {

if appDelegate.offlineStoreState.contains(.syncSuccess){ let query = DataQuery (). selectAll () .orderBy(Event.name).expand(Event.locations , Event.sessions , Event.sessionLevels)

do {
self.eventSection.events = try self.eventAppContainerOffline .fetchEvents(matching: query) completionHandler(nil)

} catch { completionHandler(error)

}
} else {

} }

let query = DataQuery().from(eventAppContainer .entitySet(withName: Collection.events.rawValue)) .selectAll() .orderBy(Event.name).expand(Event.sessions , Event.sessionLevels).page(pageSize) self.eventAppContainer.executeQuery(query){ result, error in

guard let result = result else { completionHandler(error!) return

} }

The iOS version of EventApp was completed by the implementation of ten UIViews and their corresponding UIViewControllers. The development of the EventApps iOS version took 26 working days, which is 12 days .

One reason for the speedy development is the generation of proxy classes. These classes take care of the boilerplate code, freeing up the developer to focus on logic specific to the app. The other reason is that using native tools like XCode speeds developers as all of the function to develop and debug are available on a “ripe” toolchain. Compared to developing with the Cordova stack where setting up the toolchain can take multiple days due to the dependencies on third party tools and packages. For example, debugging on Cordova is considerably slow due to the multiple layers each app has (Native, Native-JS Bridge- JS code). Each Update of any of the tools or packages could potentially break the Cordova development environment. Also the simple use ofThe Swift unit test environment helps developers find gaps and bugs faster. Unit tests stabilizes the code to ensure that every step towards the goal is not jeopardized through future changes .

Conclusion

The modernisation of Cordova applications into MDK or native mobile Application is possible and not too expensive. The application implementations during this project support considerable performance improvements through both MDK and iOS. So not only is the app easier to maintain and operate, it also has a much more responsive UI for the users. Even though the iOS application provides better performance than the MDK version, the MDK application’s performance is noticeably faster than the original Cordova app. Code generations, UI Controls, and security features offered by SAP Cloud Platform mobile services SDKs are a great development boost saving a significant amount of development time. Of course, everything which is available for the iOS platform is also available for the Android platform. So, one can use MDK app or build a native app with the SAP Cloud Platform SDK for Android leveraging the same advantages.

Limitations observed during the implementation of a unique application feature, like in-house maps, were solved by implementing custom components in different technologies. The MDK project supported this feature by implementing an Extension Control accommodating an open-source custom map HTML project. Writing native script codes integrated this open-source project into the MDK application. In iOS, this feature was implemented by adding the iOS version of the custom map project using a dependency manager for XCode. The high extensibility of native developments brought a smoother development experience. Nevertheless, MDK also could adopt the feature in a similar amount of time.

Total Cost of Ownership of Different Technologies for a Cordova applications has high maintenance cost over time, causing a higher total investment amount. MDK apps are faster in initial application implementation, and SAP’s support for the tech stack makes the application cheaper at the end. Native mobile developments demonstrated has the lowest cost among other technologies after their initial implementation. When considering investments for modernization and tackling issues of the existing Cordova app, it can be summarized that MDK causes a lower initial investment, but native development ensures a lower Total Cost of Ownership.

 

to stay tuned follow me Sami Lechner or at twitter

more details and help @ SAP Mobile

Be the first to leave a comment
You must be Logged on to comment or reply to a post.