How to publish an iOS App from Microsoft AppCenter to Apple App Store Connect

In this blog I will detail how you use Microsoft’s AppCenter to build an iOS app und publish it directly to iTunes Connect. This allows you to decouple the building, testing and distribution process from the developers. The developer only has to push the app to the repository (I am using Azure DevOps) and AppCenter takes care of the rest.

The steps to do so are:

  1. Create app project
  2. Configure build
  3. Add signing certificates
  4. Configure distribution to iTunes Connect

Create App Project

Open AppCenter and create a new project.

You can add AppCenter features to you app, but it’s optional. I already have a running app that I just want to build and distribute. Next step is to configure the build.


Select the repository where the source code is hosted. I use Azure DevOps (free tier). Unfortunately, GitLab is not listed and in the free tier I am using it is not possible to add self-hosted git repositories.

AppCenter will connect to Azure DevOps via SSO and list the available projects.

This adds the repository to the build configuration. You’ll see the branches and last commit message.

To configure the build, click on the configuration option for the branch. The option will only appear when you hover with your mouse over the branch.

AppCenter will scan the project and find the available XCode settings.

You can configure the XCode version to be used for the build. This is very useful when you are using external libraries that do not work with newer XCode versions. For instance, the Fiori libraries included in my project were not released for 10.2.1 and the newer Swift version that comes with it. Therefore, the build exited with an error. Until SAP released an updated version of Fiori for iOS, I had to use XCode 10.2.

AppCenter offers options to automatically increase the build number, or run your XCTests.

Sign build

To be able to send the app to iTunes, you must sign the build using your certificate and provisioning profile. I wrote two blogs on how to get these:

When you have these available, you can start configuring the app signing. You upload the files and provide needed credentials for your private key.


Next step is to define where you want to distribute the app to. You can send it to the official App Store, App Store Connect Users for your TestFlight beta testers, or to an internal Company Portal.

I am going to distribute the app to App Store Connect for TestFlight. Select App Store Connect. If you do not have yet an account linked to Apple, you can do this here.

AppCenter is connecting to App Store Connect and retrieves a list of apps. I only have one app available, making the selection easier. It also means that you have to create the app first in App Store Connect. AppCenter is not able to create the app definition for you.

Select the app and click on Assign.

In case 2FA is enabled for your Apple ID, you will have to provide an app-specific password. I wrote a blog an how to create an app specific password.

After informing the app-specific password, you get back to the previous screen. Click again on assign.

Now AppCenter is configured to connect to Apple Connect. Back at the Distribute builds section, you can select App Store Connect Users.


You can now click on save or already start your first build.

Run build and distribute to App Store Connect

After the project is created and the build configured, you can start a build. AppCenter will find an available build agent, clone the repository, build, test, sign and distribute the app.


Waiting for a free build agent

Build starting


After the build is done, the app is send to Apple Connect and processed there. Apple will check if the build is OK. This will take some time. The status of the build is Processing.

App Store Connect

When processing is done, you get an email form Apple.

The status of the app in AppCenter and App Store Connect changes and you can distribute the app to your beta testers via TestFlight.

Let the world know

Install SAP OCB Retail – 4 – Validation

After enabling OCB features, you should check if folders and files are correctly available in SMP3. In theory, the enablement worked, when OCB files are available in the features, plugins and webapp folder of SMP3.


ls /SAP/MobilePlatform3/Server/features/ | grep "*"

You should get a list of 5 folders.



ls /SAP/MobilePlatform3/Server/plugins | grep ""

You should get a huge list of folders

  • […]
  • […]


ls /SAP/MobilePlatform3/Server/webapps/

Three banking-* folders must exist.

Let the world know

Install SAP OCB Retail – 3 – Enable SAP Omnichannel Retail Banking

While installing OCB, SMP3 had to be stopped. During the installation, the database was prepared and files that represent the OCB application were copied to SMP3. Those bundles are now available in SMP3 (OSGI bundles), but are not activated. To be able to use OCB, the features must be activated by SMP3 administration in the Admin web interface. First, start SMP3.

Add OCB p2 repository

Log on to the SMP3 admin interface and navigate to settings -> repositories

Add the repository created above by the installer


Enable OCB features

After adding the p2 repository containing the OCB features, you can enable them. Navigate to Settings -> Features & Components.

The screen shows the available features for SMP3. With adding the OCB p2 repository, the OCB features are listed. You have to follow a specific order when activating the features.


1 Enable

2 Enable

SMP3 server will restart. You can see this on the console.

New bundles and new features are being started.

SMP3 server must start successfully. If not, you have a problem.


3 Enable

4 Enable

5 Enable

Start scheduler bundle

cd /SAP/MobilePlatform3/Server/tools/cmdclient/
./ ss banking-core-scheduleruntime

Let the world know

Install SAP OCB Retail – 2 – Start installation


Download the installation file from SAP Market place and copy it on the SMP3 server.

tar zxvf ONLRETBANK83001P_1-81000501.TGZ
cd ebf25660/

This will give you the installation files in the folder.

Start installation

The installer is the folder SAPOnlineRetailBanking8.3.1.1.

cd SAPOnlineRetailBanking8.3.1.1/
sh ./

Press enter to start the wizard. You’ll have to inform several paramters, like SMP3, Database, etc.

SMP3 configuration

Oracle Database configuration

Inform the path on your system where Oracle is installed. The path contains the DB tools. For Oracle XE, the path is: /u01/app/oracle/product/11.2.0/xe/

Load sample data into database

Installation starts

Database is being created

After a while, the installer should finish


The folder must have been created as a p2 repository. Check for it via

ls /SAP/MobilePlatform3/Server/p2/

Let the world know

Install SAP OCB Retail – 1 – SMP3 configuration

To be able to install SAP Omnichannel retail banking on SMP3 SP8, some adjustments must be done on the SMP3 server configuration.

Avoid memory leak

Add a new parameter in the props.ini file of SMP3 server.

vim /SAP/MobilePlatform3/Server/props.ini

Parameter to add: -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true

DTD validation

Looking at the installation guide from SAP, this configuration is somewhat against SAP’s own security recommendations, but is needed as OCB uses struts, and for those the validation must be done via DTD and not by XSD. Edit the file located at /SAP/MobilePlatform3/Server/configuration/

vim /SAP/MobilePlatform3/Server/configuration/

Comment out the last two properties.

Weak Diffie-Hellman ciphers

New browser don’t like anymore the SMP3 SP8 standard TLS ciphers, therefore these must be changed to be more aligned with latest security expectations.

vim /SAP/MobilePlatform3/Server/config_master/org.eclipse.gemini.web.tomcat/default-server.xml



Set JAVA_HOME variable to the one used by SMP3.

export JAVA_HOME=/SAP/MobilePlatform3/sapjvm_7/
Let the world know

Install SMP3 with Oracle DB

The following procedure for installing SMP3 with an Oracle DB is for Linux. For tests, you can use Oracle Express. Check your environment/company if you can use that version.


Ensure that Oracle XE is up and running. It is important that the tnslistener is working! Run the listener and check the status:

/u01/app/oracle/product/11.2.0/xe/bin/lsnrctl status

Configure installation parameters

The steps are documented at SAP Help. You’ll have to edit the SilentInstall_Linux.txt file and adjust the installation parameters.

vim SilentInstall_Linux.txt

For Oracle, you’ll need to change these parameters (at the end, you’ll find a complete example file):

Activate that SMP3 uses an external DB

-V developerInstall="false"
-V productionInstall="true"
-V sqlaEmbeddedDB="false"
-V existDB="true"

Inform the Oracle XE connection parameters

-V existDBType="oracle-sid"
-V dbHostName="localhost"
-V dbPortNumber="1521"
-V dbLogin="gomobile"
-V dbPassword="secret"
-V dbDBName="XE"

Inform the JDBC driver location

-V jdbcDriver="/u01/app/oracle/product/11.2.0/xe/jdbc/lib/ojdbc6.jar"

Prepare Oracle DB

Form the above connection parameters you can see that SMP3 is going to use the user gomobile with the password secret to connect itself to Oracle XE. This means that the user with the password and a schema must be created in the DB. SMP3 comes with a SQL script for Oracle that does exactly that. The script is located at /db_tools/db/oracle/smp3/sql. The file is 001_SMP3_drop_and_create_user.DDL The file contains the SQL statements to create the user with the right permissions:

-- 2 Roles for GOMOBILE
-- 1 Tablespace Quota for GOMOBILE

You’ll have to add the command EXIT; at the end of the file

To run the SQL script, run:

sqlplus system/Sap123 @001_SMP3_drop_and_create_user.DDL > smp3.log
  • Note: Sap123 is the password for the user system.

Output is written to smp3.log

SQL*Plus: Release Production on Wed Aug 24 21:37:08 2016
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Express Edition Release - 64bit Production
Role created.
Grant succeeded.
ERROR at line 1:
ORA-01918: user 'GOMOBILE' does not exist
User created.
Grant succeeded.
User altered.
User altered.

The error regarding DROP user is normal, as the user gomobile hasn’t been created before, so there is no user to drop.

Run installer

With the above steps done, SMP3 installer is ready to be run.


The output will contain information regarding the Oracle DB:

dbg, existDBType:oracle-sid
WARNING: Selecting this option confirms SMP database is already created
dbg, jdbcDriver: /u01/app/oracle/product/11.2.0/xe/jdbc/lib/ojdbc6.jar
dbg, jdbcDriver fullFileName: /u01/app/oracle/product/11.2.0/xe/jdbc/lib/ojdbc6.jar
dbg, jdbcDriverFile: /sap/SAP/MobilePlatform3/Util/ojdbc6.jar
dbg, ojdbc6.jar will be renamed to ojdbc.jar in the installation
dbg, queryExit:oracle-sid localhost gomobile [pwd entered] 1521 XE
dbg, Ping succcesful: 0
dbg, smpDataExists:false
dbg, New node install

If everything works fine, you’ll get a confirmation message at the end of the installation.

Installation Successful


SAP Help contains some information on how to validate the installation. You can search for error message in the installation log, but when an error occurs, normally the installer stops. My preferred way to check SMP3 is to start the server and see if I can log on, create apps, etc. Base test is therefore to start SMP3 and to log on.

Let the world know

Afaria – Test NDES certificate template

Easiest way to test SCEP with Afaria is to make use of the delivered ServerSCEPtest application. This application comes with Afaria`s PackageServer component. It can be found in the bin directory of the package server.

The test application is a Windows executable that executes the SCEP process through Afaria. You have two options available for the test:

  1. Provisioning Server
  2. Package Server

I am going to execute the SCEP/NDES test using the package server. This is the Afaria component used by all clients to receive a client certificate for apps.

To run the test, at least the common name value must be filled in. This is the CN= part of the certificate. Normally, this is your user id. Unfortunately, the test tool is limited to 2048 bit key (Afaria SP8) and does not select you higher or custom values. To run the test, just select perform test button. The additional CSR informations like city, org, etc are taken from the package server configuration. These values are given by the Afaria admin.

The status of the SCEP process is shown in the log area. You can see that the CSR is created and send to the package server CA. After the test ran without errors, the returned certificate is saved to: C:\ProgramData\SAP\Afaria.

The see and validate the value of the new certificate, you can use the Crypto Shell Extensions of Windows Server.

The certificate was issued by the CA: CA. Lifetime is one year. And the template is AfariaUser. This matches exactly how the NDES template was configured.

To be 100% sure, the CA can be consulted. Normally, all issued certificates are stored there and can be consulted. Taking a look into the issued certificate list, I can see that a new certificate by the NDES user was issued using as a template AfariaUser. Therefore, the new NDES configuration is validated and working.

Let the world know

Afaria – Define certificate template for SCEP on Windows CA

When you work with Afaria, you`ll sooner (iOS) or later (Android, WP) come in contact with certificates. To be more specific, with device (iOS) and user (all platforms) certificates. To make it as easy as possible to get those certificates available to the devices and users, an MDM solution makes use of SCEP. SCPE in the Microsoft world is called NDES, and is available with their CA. If you install everything following the official documentation, you`ll end up having

  1. A working environment (yeah)
  2. Most probably a certificate issue, as your users and devices get a certificate named IPSec (Offline request).

This default certificate is what Microsoft thinks fulfills most use cases of SCEP (sorry, NDES) and basically they are right. A device or user can use this certificate without problems for most of the scenarios. Most importantly, users can use it to authenticate themselves against services. It may be that

  • your security area does not like the name
  • the lifetime does not meet the requirement: its 2 years as given by Microsoft
  • it is missing some functionality
  • wrong algorithm or key length
  • or something else

All of the above points are valid and can invalidate the use of the default configuration. Which leaves you to the question: how to solve this?

To make Afaria get back from the CA a valid certificate based on a custom template, it only takes two steps:

  1. Create a template
  2. Assign template to NDES (SCEP)

With SCEP, Afaria is only consuming a service offered by CA. How the CA is treating the request, depends 100% on the CA. Therefore, no additional configuration is needed on the consuming service: Afaria. As a result of this, three steps are necessary to make Afaria get back a custom certificate:

  1. Create a certificate template
  2. Assign template to NDES (SCEP)
  3. Test
Let the world know

SAP Mobile Platform 3 Software Development Kit version management


SAP releases a software development kit (SDK) for its SAP Mobile Platform 3 (SMP3) to enable developers to efficiently create apps. The SDK is not a static product but is actively developed and supported by SAP. This means that a SDK receives constant updates and patches.


The above screenshot shows that only for SDK SP10 7 patch levels were released, in a little more than 1 month. The installation of a SDK is always done in the same location. Therefore, only one SDK version can be used at a time be a developer. While this assures that only the latest version is going to be used, it creates a problem in regards to maintainability and ongoing development. A new development project may use SP10, while a current one may still depend on SP9. To overcome this, a developer may create local copies of the SDK and manually switch between the different versions, an approach is going to be presented in this document that allows the developer to have different versions of the SDK available.


The approach consists of using git to manage the individual versions of the SDK. Of course, a different revision control system may be used, but git offers normally a superior handling and speed. The overall process is as followed:

  1. Create an initial version of the SDK.
  2. Add this version to git and tag it correspondently
  3. Install a newer version of the SDK to the same location
  4. Use git to add this version and tag it correspondently
  5. The work with a specific SDK version, the developer checks out the needed version
  6. If necessary, remove/add the Kapsel plugins / libraries to a project
  7. Repeat step 2 to 4 for future versions


Download initial version of the SDK from SAP Market Place:

Path: Sybase products -> SAP Mobile Platform SDK -> SAP MOBILE PLATFORM SDK 3.0 -> Support Packages -> SAP MOBILE PLATFORM SDK 3.0 -> [OS]

Install the initial version of the SDK

Go the the installation folder. Either opt to version the whole installation folder or just a part of the SDK, like Kapsel. The following example will only version Kapsel.

Note: by default, Fiori Mobile Client apps are stored inside the Kapsel SDK folder. As each FMC app adds a few thousands files, it is a good idea to not have these included into the git versioning. Consider using .gitignore for those folders.

Initial commit and tag

  • Initialize the folder: git init

  • Add all content: git add –A –v

  • Commit files: git commit

  • Tag commit: git tag –a SPnPLm –m “SDK SPnPLm”

Updating the SDK

Download a newer version of the SDK and install it. Ensure that KapseSDK is going to be upgrade (which should be the default).

Go the installation folder to add the new files to git.

Note: it is important to know that with git a folder .git is created which stores all the git relevant information. In case this folder is deleted, so will also the files and versions added to git. Normally the SDK installer is only overwriting and adding files and not removing. The .git folder should therefore not be impacted by the SDK installation / upgrade process.

Subsequent commit and tag

  • Add all content: git add –A –v
  • Commit files: git commit
  • Tag commit: git tag –a SPn+1PLm+1 –m “SDK SPn+1PLm+1

Add files

Files that were part of the previous SDK version but not of the current one will be shown as remove.


Tag version

See available SDK versions

Use a specific version of the SDK

To use a specific version of the SDK, it must first be stored in git and tagged. To use the version, a simple checkout is sufficient to update the whole KapselSDK folder to the specified version. To make use of this version, the Kapsel plugins must be updated in an already used project. For a new project, the usual process of adding a plugin is to be used.

  • List available versions: git tag
  • Checkout version: git checkout

To complete the installation, install the Kapsel dependencies as described in

Let the world know

Use a specific Cordova version for hybrid app development


Cordova is used as the de-facto standard software for creating hybrid mobile apps. To keep up with mobile platforms, a new version of Cordova is released constantly. This creates a certain challenge for mobile app developers that have to not only create new apps, but also have to maintain older versions. Specifically in enterprise environments, it is not always possible to simply update to a new Cordova version. One reason can be an upcoming go-live. You do not want to change your SDK days before a go-live as this increases drastically your testing efforts. For instance, SAP releases a software development kit (SDK) for its SAP Mobile Platform 3 (SMP3) to enable developers to efficiently create apps. The SDK is not a static product but is actively developed and supported by SAP. This means that a SDK receives constant updates and patches. Each SDK SP version comes with a minimum and recommended Cordova version. A developer that has to create new apps and at the same time maintain older versions may come into the situation where it is necessary to have not only different version of a SDK SP installed, but also of the Cordova tool. Given a normal workload, the developer may have to change between the new project and the maintenance several time per day.


The above scenario creates the following problem for the developer: by default, Cordova is installed via npm globally. With this, only one version of Cordova is available at a given time. For the developer this means that he cannot simply have several versions for each SDK SP and project available. A manual remove of the current version of Cordova and install of the needed version is necessary. As the npm install is globally done, one version of Cordova is activated for all users of the computer.


The root cause of the problem is how Cordova is installed. Cordova is delivered and maintained via npm. The default way of installing Cordova is to issue the command:

npm –g install cordova[@{version}]

Install locally

npm offers alternatives to the above shown installation option. Without the –g flag, a npm module will be installed into the nodes_module folder of the current path. To install Cordova locally to the project folder, the command is:

npm install cordova[@{version}]

With this, Cordova executable is available at node_modules/cordova/bin/cordova

A cordova –v run against the newly installed version shows that the right version is installed.

To create a Cordova project with that version, this newly installed version must be used and not the globally available version. The command line parameters are not affected by this.

node_modules/cordova/bin/cordova create hello HelloWorld

To add Cordova platforms or plugins, the Cordova version inside the local nodes_modules folder must be invoked.

node_modules/cordova/bin/cordova platform add android

node_modules/cordova/bin/cordova plugins add cordova-plugin-console

The same rule applies for compilation, build or run of a Cordova app.

node_modules/cordova/bin/cordova compile

Install locally (advanced)

Installing Cordova locally as shown above still means that the Cordova package must be installed before a Cordova/Kapsel project is created. To have several version of Cordova available in that way, several folders must be created, preferably containing a version tag of the installed Cordova. This implies that inside the actual hybrid project, no reference to the needed Cordova version is maintained, despite the SDK SP dependency.

To have the Cordova version tight into the project, any Cordova version can be used to create the project folder structure. Inside the folder the needed Cordova version can be installed locally. That way, the Cordova version is made available inside the project, making it easier to share the project or to onboard new team members. On the contrary, instead of having one single repository for each Cordova version, the executable must be provided for each project.

NPM link

NPM comes with a link tool. This tool links a package globally. This makes a local package globally available. The local package will appear as it was installed using npm install –g <package>. The link tool is handy when the npm package is available via its source code (like GitHub) and is therefore not needed to be installed from the npm repository.

In combination with Cordova, npm link allows to make a checked out version of Cordova globally available. A local available versoin of Cordova downloaded via git can be checked out and activated by npm link. To activate a specific version, this version is checked out via git and then activated by npm link.

The installation procedure is as given by Cordova.

git clone
cd cordova-cli
npm install
sudo npm link
npm link plugman

To go through each step:

git clone

npm install

npm link

To check the currently activated version of Cordova: cordova –v

To switch to another version of Crodova, git is to be used. The following example shows how to switch to Cordova 4.0.0 globally. First, get a list of tags from git: git tag

Checkout version 4.0.0.

git checkout 4.0.0

npm install

npm link

The check that version 4.0.0 is now available globally, issue cordova –v from the command line.

To test that Cordova 4.0.0 is now being used, create a new project: cordova create TestSAP TestSAP

Add android as a platform: cordova platforms add android

Please note that android platform version 3.6.4 is used, and not 4.1.1 as it was with Cordova 5.4.1

Let the world know