How to download your iOS distribution certificate

To be able to sign your app and let an external build tool like Microsoft AppCenter upload it to iTunes Connect, you need to provide two files:

  • Certificate: iOS Distribution
  • Provisioning Profile: App Store

Microsoft provides technical documentation on how to get the code signing certificates and how to upload them to your build pipeline. I’ll try to add more explanation and screenshots to make it easier to get both files. This blog is for the iOS distribution certificate.

Distribution certificate

I need the correct distribution certificate for the provided provisioning certificate. The provisioning profile contains a list of “linked” distribution certificates. If yours is not in the list, you cannot use your certificate to sign the app.

Get certificate

Log on to Apple Developer Center. Select Certificates, IDs & Profiles from the left menu

I have several (3) certificates available.

Which one is it? When I created the provisioning profile, I added a distribution certificate. I only have one, so this is the certificate I need.

To be able to use the distribution certificate in an external tool like Microsoft AppCenter, I have to convert the certificate into a p12 file. To convert, you can import the certificate into Mac Key Toolchain, export cert and private key and save as p12.

1. Download the certificate

2. Check file

The downloaded cer file is named ios_distribution.cer. The see if this certificate is for distribution just read the content using more. It must contain the line iPhone Distribution.

more ios_distribution.cer

3. Import into keychain

Open the certificate in MAC Keychain.

I also have the private key for that certificate.

4. Export

Select the certificate and private key and export both. Save the file and provide a strong key phrase.

Now I have my personal distribution certificate (Zertifikate.p12) and provisioning profile (.mobileprovision).

Let the world know

Small Wishlist for SAPPHIRE

SAP’S prime event SAPPHIRE is happening next week. Of course SAP will talk about how great they are, how latest acquisitions add value, the new additions to the excellent portfolio, that customers are doing great thanks to SAP, and so on. It’s an event driven by marketing and sales, what else to expect?

Personally, I’d like to see some announcements that won’t happen, and won’t be announced at any other SAP event. Nevertheless, here is my personal list of things that I believe could add value to SAP’s overall ecosystem.

Trackable announcements

As with every event, there will be a lot of success stories and product launches and should padding and everybody on stage is either a friend, longtime friend, or for companies, it’s a very special relationship. And all about how great the product is. Why not make it easy to track the success? Of course S/4 is big. What about the other announcements? If it’s announced, provide a way to see how well the product is performing. Make transparent what happens to the product after SAPPHIRE is over. Bring the customer back on stage. Let them talk about the last 2, 3 or 5 years. For instance, what happened to the Leonardo solution for analyzing the health of palm trees? Is the intelligent vending machine used in the market? How is the cloud service for tax calculation performing?

Bring back apps

SAP is really good in delivering solutions for core business processes. For the additional problems, SAP tries to offer tools to customers that make it possible to create missing solutions and apps. What a customer gets is a toolset to develop, not a solution. If you want to have a mobile app for “standard” functionality today, you have to develop it. For large companies this is not a problem, for smaller one it can be, for everyone it means that they are responsible for developing apps. And to support them.

Once we had mobile workflow from Sybase / SAP, a packaged app for mobile. Afaria was a leader in MDM. Both were sold together and client got for one price a complete mobile solution. Today you can automatically create an offline enabled app using for instance mobile cards or the new mobile development kit. Using these, you develop following standard guidelines. Every partner or freelancer can offer the very same app for a customer.

The available toolset is good enough to create apps out of Fiori apps, Mobile Cards or Mobile Development Kit. Many customers want the apps you can develop with these but do not like the idea of doing this. And having to deal with all the licensing and support issues. Make it easy to offer the developed app as an app with all licensing included. SAP could provide the standard documentation on how to create an app for a given process using the toolset from SAP, and let partners either create apps following 100% these guidelines or let them add additional features. In both cases, customer can buy what is needed, with full support from partner and SAP, and without having to license all components involved. In case customer wants to change the partner, the app is build using standard recommendation, another partner can offer the exact same app.

Redefine SAP portfolio

Trusting partners to deliver the kind of apps as they were delivered by SAP means to rethink SAP Consulting positioning and its portfolio. Once SAP Consulting was a powerful organization with competent people helping customers. From technical side, the good consultants largely left. From a functional point, situation is much better. Would be nice to see SAP consulting focusing solely where it can still offer value to customers: functional consulting. Let SAP’s own consultants advice customers on how to improve their business processes. How to do accounting using S/4, Retail or supplier management. Let everything that even slightly touches technical area complete handled by either a partner or freelancer consultant. Same for support. It’s time to stop letting SAP support people act as consultants.

Simplify Cloud

When SAP executives look at it, it must be a dream for them: customers buying HEC, cloud numbers go up, only good feedback. What enters the system and bubbles up is filtered. The lower you go at a HEC project, talking to people actually working on a daily basis with HEC, situation changes: System not correctly configured, unavailability, bad support, and so on.

Personally I had so far: HANA system that wasn’t updated for years, Gateway system with language pack not correctly installed, systems unavailable because support restarted it in PRD without informing anyone, missing components like Web Dispatcher. My personal favorite: 24/7 support from Monday to Friday during Indian business hours.

It’s time to announce when SAP is either closing HEC or restarting it’s offering. Same for SCP. Neo, Cloud Foundry, it’s nice to have choice, but please close one. Announce if Neo is going to survive or not, and give a final date. Also, separate SCP services by user groups: developers & business. Business side is interested in solutions not developer services. Give each group one view at SCP and services. A possible end of this could be to close the developer part of SCP. Bring the tools to multi cloud, aka: offer them on AWS, Azure, etc.

Fiori

SAP pushed Design Thinking and provides helpful tools and guidance on how to enable it. Many customers started to use DT thanks to SAP. The initiative slowed down. Development on Build and web site seems to be at minimum effort. I would like to see SAP investing more into BUILD. Make all UI5 controls available, integrate Bootstrap controls, include controls for iOS, Android and material design. Make it a design tool not only for SAP content, but for everything. Make it the design and mock tool at companies. To speed adoption of UI5 outside SAP context, make all UI controls part of OpenUI5. Include better support for non-OData backends.

None of this will be announced at SAPPHIRE. I just wrote this down to be able to look back in a few years to see if some ideas were good. There are additional ideas that are more suitable for TechEd, like: make S/4 architecture ready for Kubernetes. Having a work process running as pod in K8S makes it easier to scale an SAP System. Allowing arbitrary databases as backend for SAP CAPM. Add SAP technologies to Swagger (OpenAPI). Deliver software via Git. Long time topic from me, think I mentioned this around 2011 in SCN. For instance, instead of installing Fiori Apps the traditional way, let me select the app in Git and import only this app and run also the included tests. Reduce drastically RAM footprint of HANA. And many more. Maybe I will write a similar blog for next SAP TechEd.

Let the world know