The MDK framework allows you to create hybrid apps easily for iOS and Android. Although the framework has a lot to offer, it might be missing some native functionalities. The MDK framework allows NativeScript plugins but even that is not always enough. In those cases, it might be necessary to use native iOS code when building an MDK application. As an example Robbe shared a blog post on NFC scanning where he used native iOS code: MDK iOS NFC UID Scanner – How to use native functionalities in SAP MDK using Swift and debug on Mac | SAP Blogs .
Besides the NFC requirement of Robbe, other requirements could also require native iOS code. In this blog post, I’m going to share a more simplified HelloNativeWorld example on how to do this. I’ll share the minimum steps you need to do on every layer of an MDK application to run custom native iOS code.
The setup requires to have a Custom MDK Client with a Native iOS class and a custom MDK App:
Let’s start by configuring the MDK application in Mobile Services:
Mobile Services Configuration
Before we start I will create a new MDK Mobile Application in Mobile Services with a unique id. Mobile Applications ⇒ Native/MDK
Click on “New”:
Here, I provide an ID and name for the application (the same id is needed for your signing profile):
I leave all other steps on with the default configuration.
Security settings:
Assigned Features:
That’s it for now in Mobile Services. Let’s start coding.
Native iOS Code
As a first step I’m going to create a basic iOS swift class that I will call from in the MDK application later on. To do this I created a new empty project in Xcode:
Choose a template ⇒ Other ⇒ Empty
Select your Team and give the project a name, this will create a new Xcode project:
In this created package I created a new Swift File by going to File ⇒ New ⇒ File:
And select “Swift File”:
Provide a name for the Swift file:
In the swift file, I create a simple class with a function that I will use later on in the MDK application. A few remarks that are important to know:
- @objc is needed to make the class and function accessible from in NativeScript
- The class needs to extend from “NSObject” otherwise the build will result in errors
This will result in a project with one single swift file containing a class:
The native iOS code needs to be stored somewhere so the MDK application can access it. This can not be in the MDK application itself. It requires a Custom MDK Client that contains this swift class. Next step is to create a Custom MDK Client.
Custom MDK Client
After creating a Native iOS Swift class, I need to create a custom MDK Client. The steps to do this are already described in the following tutorial, step 3: Build Your Mobile Development Kit Client Using MDK SDK | Tutorials for SAP Developers
There is also a tutorial to make a custom MDK client using Mobile Cloud Build:
Build Your Mobile Development Kit Client Using Cloud Build Service | Tutorials for SAP Developers
Nevertheless, I will go through the steps I did to make it work. I will use the cloud build, in that case not all steps are required and you don’t have to install anything.
First step is to download the MDK SDK: Developer Trials and Downloads | SAP Developer
Unzip it and in the MDKClient_SDK folder, you will find the template.mdkproject folder. Make a copy and rename the folder something else, I used the following: “helloworld.mdkproject”
Copy the swift class created in the previous step into the folder “App_Resources/iOS/src”. Pay attention to the “src” folder, this one is not there by default and needs to be created by you.
Configure the MDKProject.json accordingly to the created MDK application in Mobile Services:
Copy the “Connection Settings” from Mobile Services to the file “BrandedSettings.json”. The “Connection Settings” can be found in Mobile Services ⇒ Assigned Features ⇒ Mobile Settings Exchange ⇒ Info
Zip the .mdkproject folder and upload it to the cloud build service.
In the earlier created MDK project in Mobile Services, Cloud Build is one of the features that is assigned by default. You need to go to the list of features and click on”Mobile Cloud Build”. This is the place where you have to upload the zipped mdkproject:
Create a new Build Job:
Give the job a name and upload the zip:
In my example, I kept all default settings and only changed the iOS Build Options:
Once it is uploaded, a build can be triggered by clicking on “Build”:
As soon as the build is completed, a QR code will appear that you can use to install the Custom MDK Client:
Custom MDK App
Last but not the least, I created a simple demo application that will access the Native iOS code. I started from the basic template “MDK Project”:
Give the application a name:
This will generate an MDK project with one empty view in. For testing the Native iOS code, I added a button that trigger a rule:
The “OnPress” event behind the button is connected to a newly created rule:
Generate a rule in the “Rules” folder using the wizard:
I give the rule the name “sayHelloNativeWorld”:
With the following two lines, I’m able to call the native iOS code:
- Create a new instance of the Swift Class
- Call the native function “whoAreYou” using the instance
You’re good to go! Deploy the custom MDK application to Mobile Services by right clicking on the “Application.app” file and click on “MDK:Deploy”:
Testing
We are ready to give it a try. Install the custom MDK Client which will load the deployed custom MDK application and you’ll see the following two screens:
- A view with the button
- An Alert with some text that comes from the Native iOS code (after clicking on the button)
Resources
This is a very basic example starting with the basics and perfect to get you started with Native iOS code in Custom MDK Apps, all resources can be found on GitHub: lemaiwo/MDKHelloNativeWorld (github.com)
For a more advanced use case and debugging you can have a look at the blog post shared by Robbe: MDK iOS NFC UID Scanner – How to use native functionalities in SAP MDK using Swift and debug on Mac | SAP Blogs
A very useful resource that helped us putting the pieces together is this example:
Special thanks to Robin Kuck and Robbe Wuyts to make this work!
