The influence of the SDK for iOS on the SAP and iOS community
On March 16th, we celebrated our annual VNSG developers day. A day fully dedicated to developers and developer topic. We had magnificent content, both from the hearts of SAP as well as the community mostly accompanied by nice demos showcasing SAP’s latest and greatest.
One of the nicer demos was presented by Twan, who took a photo of the audience and used Machine Learning mechanisms to recognise faces and perform an age, sentiment, and gender analysis on the recognised faces.
The results struck me in a way. Of course we already knew that the majority is male, sentiment on a day like this is positive, and the age analysis looked quite flattering as well. But when I did a personal analysis on the faces without machine learning, it struck me that the age of developers in the (Dutch) SAP community is steadily increasing.
The day before the VNSG Developer day, I attended a lunch organised by the Appsterdam meetup group. I was really curious about this meetup group, their topics and the people behind this community. They happened to be able to pass me a free ticket to the AppDevCon conference that would happen that same Friday, just after the VNSG Developer Day. The AppDevCon is a conference specifically for app developers on both the iOS as well as Android platform.
While I felt like one of the youngest when I was on the VNSG Developer day, I felt like one of the eldest when I was at AppDevCon.
Enterprise back-end
When I was at the AppDevCon, I took the opportunity to talk to some of the other visitors to see if they had ever built application on top of enterprise back-ends such as ERP or CRM systems and whether they had ever heard of SAP.
I absolutely hit a pain point there. Most of the response had to do with headaches around message brokers and integration platforms. OData and Gateway are technologies they had never ever heard of.
When I tried to explain to them what it was and how SAP currently does integration, the discussion quite quickly went into the direction on how these things could be done using the shiny popular frameworks such as React and Angular or their native counterparts such as React Native and Nativescript. When it came down to OData and integration protocols, I was quickly pointed in the direction of GraphQL or got the counter question “what’s wrong with regular REST?”
It became clear to me that the intention of the participants of the conference isn’t really the integration to the back-end. That part is definitely not sexy. What’s more important is what the app looks like and how to build it with as little effort as possible.
Fiori
I have tried to explain about the Fiori design language to some of the attendees and have also explained how this would be integrated into SAP Cloud Platform SDK for iOS. That its objective was to increase developer productivity and contribute to a consistent user interface. Unfortunately this didn’t hit a sweet spot as well.
Although the people I talked to could imagine that this would be beneficial if you would launch an array of products in a large company, this was definitely not their focus area. Most of the times they were hired for an external facing, mostly consumer type app or a one off app an in those cases they just found the Fiori design language too rigid.
Especially from a design point of view, they wanted to have more freedom to adjust the app to the overall experience of the user in that particular app, without caring to much about the world outside of that app. It also seems that the design language they were talking about, had more to do with animations rather than consistency. They believe that with those little extra’s they would be better able to capture the user’s emotion than with a consistent user interface.
SAP Mobile Services
When I spoke about the mobile services on the SAP Cloud Platform and was explaining about the features of the cloud platform in combination with mobile services, at a certain point they understood what I was trying to say and they started comparing the SAP Cloud Platform and mobile services with Google’s Firebase, which admittedly has quite an overlap in functionality.
I was explaining that emphasis would of course be on back-end connectivity and various business services such as analysis, integration with IoT, enterprise social and others. They mentioned that in most cases, they weren’t tasked to do these kinds of things, but these things were taken care of by developers in the back-end teams. Although none of the folks I spoke to knew about the SAP Cloud Platform, they would consider looking at it when they would be asked to take care of similar back-end tasks. There! Mission accomplished, finally something I could at least trigger their interest with, although not to the extend that I hoped for.
SAP Cloud Platform SDK for iOS
During various sessions we held at the VNSG special interest group meetings, but also at the developer day, we noticed a vast interest in the SAP Cloud Platform SDK for iOS. One of the reasons that I was at the AppDevCon was because I would be interested to know whether (non-SAP) iOS app developers would be interested in the SDK as well.
I’m afraid that the SAP Cloud Platform’s Mobile Services is not on their radar screen, and it is of course to early to ask about the mobile SDK (thanks for your highlighting this, Pierre). However, there is a good interest in Google’s Firebase, and I believe that SAP Cloud Platform SDK for iOS could be the Firebase for enterprise mobile developers. There is quite an overlap in functionality, and consumer-type services such as ad-provisioning are replaced with analytics and integration services, making the SAP Cloud Platform a good contender to take the place of mobile platform of choice for mobile enterprise app developers.
It seems that Firebase is setting a de-facto standard in this area though, and it would be wise for product teams behind the SAP Cloud Platform SDK to keep a close eye on what is happening in this field. Especially the continuous client synchronisation is praised by many, leading to an always synchronised offline version of the database, without any additional developer effort.
Another part where the SAP developers may have to take a peek into are the number of Cocaopods the SDK consists of. Currently the SAP Cloud Platform SDK for iOS has three SDK files, while the Firebase SDK can be included in an app on a much more granular level, which may lead to less bloated apps. Note: Swift apps are currently a bit on the heavy side anyway, and the SDK doesn’t make that much of a difference. But it is my expectation that Apple will be able to improve this as well. To make sure that the SDK doesn’t become the “weakest link”, it would be nice to more granularly select the SDK parts that are going to be included in the app.
The Firebase SDK allows developers to configure the framework using plist files. The SAP Cloud Platform SDK for iOS only allows developers to configure the framework in code. It is my personal opinion that the configuration through plist is quite elegant and it would be nice to offer this as a configuration option as well.
SAP developers vs iOS developers
One of the questions I have been asking myself is who will up the SAP Cloud Platform SDK for iOS. Will it be the SAP developers learning Swift and Xcode, or will it be iOS developers trying to understand how SAP, the SAP Cloud Platform and the iOS SDK will fit into their tool-chain.
There have been quite some discussion in the Twitterverse about SAP developers having to pick up yet another language and development environment after they have only still recently been pushed in the direction of Java, front-end Javascript for UI5 and back-end Javascript for XSJS and Node. As a result of this, having to pick up another language generated a bit of negative sentiment amongst the Twitterati involved in this discussion.
On the other hand, it may also be just a luxury problem when there are so many modern development environments and languages to choose from. And the front-runners will always be looking beyond what they know, and will be happy to keep up and learn new things. I do expect the SDK for iOS to be picked up by the same people that were also the first to pick-up XSA and UI5. For these polyglots, another language will be just another challenge, if at all. And SAP has done a tremendous job to make this experience as painless as possible. Developers already familiar with the UI5 tooling will feel quite at home when they understand that the Assistant is very similar to the WebIDE templates, that the SAP Fiori for iOS Mentor app is quite similar to UI5 Explored, that the SDK is quite similar to the KAPSEL SDK, and that the SDK is very well documented, just like the UI5 SDK.
The question remains whether iOS developers will see the value of the SAP Cloud Platform in combination with the SDK for iOS to simplify the connection to the back-end and will they accept that the SDK will be working slightly different from what they are currently used to (e.g. Firebase)?
In the past I have seen pure Javascript developers getting hired by the boutique SAP consultants for their UI5 projects. With good Javascript background and some experience with other data binding frameworks, I heard that it is not very difficult to understand UI5 and get started with it. I expect that the same will be true for the SDK for iOS. Developers that are already proficient with Xcode and Swift will be able to understand how the SDK works easily. With the SDK documentation, the tutorials and the Academy in place, it will be easy to to quickly get started with the SDK and the system landscape behind the SDK.
Ultimately, it would be great if iOS developers would see the SAP Cloud Platform and SDK for iOS as part of their tool chain. Perhaps the SDK could be for enterprise what Firebase currently is for consumer-type applications. The SDK may need to offer a slightly more similar feel to Firebase though, which means it would have to break with the patterns that it has in common with the KAPSEL SDK.
Concluding
There’s a massive difference in the iOS and SAP community. Not only in the tool chains and frameworks of choice, but even in demographics. It is a question whether these communities will grow together organically, and the SAP community could certainly use some young blood.
To get iOS developers on board, it may be necessary to provide an enterprise toolchain that is similar to the tools they are already using. Equally important are the education and continuous developer relationship building within this community.
Looking at the interest in the SDK for iOS at past events, the SAP community is probably going to embrace the SDK for iOS without much effort. People that were early adopters of technology such as XSA and UI5 are likely to be the early adopters of the SDK for iOS again.
There is one thing that the iOS and SAP community have in common. They are both spoiled with choice in the area of modern development environments, frameworks and languages. With the SDK for iOS in place, there will even be more choice for enterprise app development. It will be very interesting to see how these communities adopt this new technology, evolve, and hopefully grow towards each other.
Let me know what you think?
Great to see you went to AppDevCon.
And thank you for sharing your insights.
I skipped it this year, but in the years I went, I had pretty much the same experiences. There is not much focus on the back-end side and especially not on the larger platforms like SAP.
About the SAP side, I wholeheartedly agree with you. The challenge will mostly be getting customers to use the SAP Cloud Platform (instead of the on-premise SAP Mobile Platform).
From the native iOS developer perspective, yes it will be harder to get people on board. However I believe as well, that you can indeed easily recruit native iOS developers and get them quickly up to speed with the iOS SDK for SAP CP. Just like you mentioned happens with Javascript developers and UI5. With the challenge mostly being, keeping the ones who like to work with all the flashy stuff happy, as an Enterprise environment usually requires a bit more certainty and stability.
But getting them to drop platforms like FireBase for the SAP Cloud Platform will be a lot harder. With a platform like FireBase you can start for free and in case your app usage rises and it’s necessary, the paid plans are a lot less expensive than the SAP Cloud Platform.
If you want to get the Cloud Platform as an alternative for FireBase, that will be the biggest challenge. (And yes of course the SAP Cloud Platform and HANA offer much more than FireBase).
Hi Jan!
Nice post and I’m jealous that you get to go to both the SAP sessions and the AppleDevCon. But I think you inadvertent discovery of the aging of the SAP developer population vs the non-enterprise developers is a telling one.
SAP tools and platforms remain a niche area that are only utilised by SAP developers. They may be brilliant, indeed I think in some area SAP is well ahead of the rest of the pack. The problem is I am 1 in 10,000 in thinking this (conservative estimate I fear). Those with plenty of experience in enterprise development (hence older) appreciate the ways that SAPs tools work with an enterprise way of doing things (translatable, solid, standard, accessible, enhanceable, etc). Whereas those that are used to pushing code changes to production every few hours just don’t understand. Why would you want your app to look like it is an SAP app? (Hello UI5 I can see you from across the room, you can’t hide.) Of course if you’re using this as an enterprise-wide approach, it makes sense. Thankfully for the livelihood of all of us aging SAP developers, enterprises have architects that insist on standards and enterprise-wide approaches.
In the meantime, however, our younger, and likely less well paid, colleagues in the non SAP developer space will continue to use whatever framework offers the best(fastest/easiest) result and most jobs. Since to get a job in the SAP space customers are used to asking for a minimum of multiple years of experience, it’s hard to get a gig – so it’s much more profitable to just develop in Firebase, Angular, etc and get a job. After all, having a paying job is quite often more important that working with your framework of choice.
I am sure that many of us older SAP devs will hire many people and teach them the minor cross-over skills to be proficient in the SAP iOS SDK, and we’ll probably make a decent amount of money from the companies that have architects that insist on SAP UI5 looking applications. But I don’t think this will change the overall conversation. In another 3 years, the developers in SAP will have aged another 3 years (there will still be a huge demand and the pay will be too good to move on). A bunch of new talent will have been trained in the new tools and will by now have 3 years experience and will be able to find enterprise SAP jobs of their own, but we will be no closer to getting anyone to adopt SAP tools for anything other than SAP customer usage.
Grim outlook – sorry. The alternative (as I see it) is that SAP gives up on building its own (even if open source and rather excellent) frameworks and just starts adding to some existing ones. All of a sudden instead of trying to convince people to use a new framework, you ask them to use a variant of one they already know. At the same time SAP invests some serious money into “public API first” development and makes everything in S4 and their other cloud products able to be accessed and updated via well documented APIs. (Thus the end of the need for ABAP developers and those who understand the black arts of the SAP APIs.) The costs per developer hour plummet and then we see a new group of developers helping customers realise their dreams. And some very happy customers.
As for the SAP iOS SDK, I think it has a very niche area, even more so than standard UI5 development. Not only is it specific to a requirement that only a large SAP customer would have, it’s also mobile platform specific. Given that it will not translate to Android devices I fear that it will not interest the generic mobile app developer. Due to being quite SAP specific quite probably not the iOS only developer either. We’ll see SAP devs training up or being hired & trained for specific tasks, not adopting the platform just because it’s cool.
Perhaps I’m just being too much of a grumpy old git (meant in the non-awesome code sharing/management/versioning way) and we will find that these open frameworks are adopted. That would be awesome. It would make a lot of SAP customers a lot happier too to be able to have some decent choice as to who to do their work.
Cheers,
Chris
Hi,
Come on, it was released today! 😉
Cheers,
Pierre
That totally makes sense Pierre. At the AppDevCon I haven't specifically asked about the SDK for iOS though, but in more generic wording, e.g. "Did you know SAP has a cloud based offering for enterprise mobility?". I have changed the wording in the blog slightly to reflect this better. Thanks for noticing this and feeding it back! ?
This is great, Jan! Bridging two (or more) worlds for sure -- i think you hit the crux here:
I've long been wondering whether the addition iOS (and GCP coming soon -- and Cloud Foundry) can make business "cool" again, whatever that means, but to me, the more diversity of people come together to create technology, the better that technology will be able to serve that diversity. Excited to stay tuned -- keep bridging gaps!
I believe that SAP has made a lot of very cool products in the last few years. But the issue is to get that word out. SAP is doing quite a bit in the area of developer relations, but the amount of developers they need to target is steadily increasing with every new framework, tool or SDK that is released by SAP. After the Javascript developer population they were hunting after, they would now have to target the iOS community as well. Both are by themselves multitudes larger than the entire SAP community already. I guess for Developer Relations this will be quite a challenge to get a certain share of voice to promote the SAP toolset that has been built and could be used by these communities. And then there’s always the issue of benefits of course. What’s the return for SAP with a relatively low share of voice?
Shortly after I wrote this blog, I found this really nice slide deck by Thomas Grassl on how developers find, learn, master and succeed with new frameworks. Although the accompanying talk is missing, most slides speak for themselves: https://www.slideshare.net/thomasgr/developer-engagement
As for diversity, I think the SAP community really needs some new blood (amongst others btw). Bringing together people of different ages can generate ideas or perspectives that otherwise may not have ever considered. Everyone has their own way of viewing a problem, shaped by the individual experiences that they have had. When tackling an issue, wouldn’t it be better to have multiple interpretations and approaches, rather than everyone contributing the same thoughts and conclusions?
Some interesting thoughts, Jan. I think the optimal team will be a mix of SAP specialists and swift devs. They will learn a lot from each other!
I've worried for a while about where the future leaders in SAP development will come from. Many companies no longer offer junior onsite roles. Hopefully this sdk will take off, suck in lots of swift devs and some of them will stick around and get into other technologies in our ecosystem.
I'm keen to get started once I have a matching requirement.
Hey Mike, I just replied to Moya on why I think age diversity is important. I think this also applies to the junior/senior issue you're mentioning. I always experienced junior project members in my projects as a source of fresh, out-of-the-box ideas. It would be a loss not to offer them onsite roles.
I think any manager that thinks otherwise should go to one of the SAP Innojams in which student teams participate. Just observe the chemistry in those teams. Mix that with a few seniors, and you're going to be unstoppable!
Hi Jan.
While time will tell how widely the iOS SDK is adopted, and by who, I have a different concern.
For any non-trivial application the UI framework of choice, be it UI5, React, Angular, or Native via the iOS SDK, is just the tip of the iceberg when it comes to application development. The real complexity is in the backend – where the proper use of application architecture moves you from the defacto “big ball of mud” to a more clean and maintainable result.
I fear that with many of these frameworks heading to a more “follow the bouncy ball” model, even less time will be spent thinking about the back end that these applications will rely on, even though we are currently seeing an increase in capability and complexity in this space too.
If we look at some of the great presentations from companies such as Twitter and LinkedIn on their development practices, there is a huge emphases on architecting the back end to meet the needs of the users who are consuming these new front end applications.
I know i’m not putting up any solutions here – maybe just hoping that the sparkle of the new front end tools don’t entirely blind development teams from the further backend architecture needs to make these applications meet expectations.
Beware what lies below the water…
?
AT
Hi Alisdair,
I fully agree with you there should be a strong focus on the backend -- but the focus should be slightly differently now.
Of course, the backend is the one truth, and it should ever remain so, but it shouldn't be no longer the backend dictating what's being shown to the user, and how. Rather, the user (front-end) should dictate what it want from the backend. This obviously adds extra work in layers like Gateway to map the "rigid" backend structures to a lean OData service required by the frontend -- in other words, backend / middleware architecture should definitely have high emphasis and should be as solid as possible, but IMO the whole architecture should start with the user (frond-end) in mind.
Hi Robin.
Couldn't agree more. If anything I'm looking at how to minimise any coupling between front end and back end. This is where good architecture becomes paramount.
Even some simple ideas such as Layering ( as discussed in Domain Driven Design et al) will make a huge difference to the final outcome. That said, I believe strongly that the Hexagonal Architecture pattern originally proposed by Alistair Cockburn (http://alistair.cockburn.us/Hexagonal+architecture) and demonstrated in Implementing Domain Driven Design (Vaughn Vernon) is where we need to end up to build successful applications in this new world.
🙂
AT
Hey Alisdair,
Is't quite interesting to see your reply saying "It's the back-end, stupid" and Robin replying with "It's the front-end, stupid!", yet being in agreement. Such an awesome community of harmony we have! ? And the truth is probably somewhere in the middle? Fact is that both need to connect somehow and the combination of the front-end and back-end should offer the user value.
Anyhow, I don't think it's the objective of the SDK for iOS to obfuscate or hide the back-end. The data models and services shaped in e.g. gateway will remain visible for iOS front-end developers using the SDK. The SDK turn these models into Swift classes, but with exactly the same properties and logic. The SDK for iOS does mean to hide some of complexity of the middle-ware layer though, including authentication, user on-boarding, CSRF security and the likes.
Don't worry about not putting up solutions for the back-end here, the SDK also doesn't do that. And in my opinion that is actually a good thing!
Excellent blog, Jan. Have to admit I opened it just to have a cursory glance but ended up reading it with great interest, especially your insights into "the other developers' world".
This blog as well as the comments seem to echo some of the points made by James Wood here. If the SAP developers are not so keen on developing consumer-grade frontend and hip non-SAP developers are not interested in the ugly backend then perhaps we simply should work together instead of trying to convert each other into our respective cult? 🙂
Hi
I have read about SAP Cloud Platform for iOS SDK and I have tried to make an app by following this link :
https://www.sap.com/developer/tutorials/fiori-ios-hcpms-sdk-assistant.html
It is simple and you have an app linking up against a SAP Cloud Platform trial version.
But I am a little confused.
How can you link up to you own SAP HANA/S4 platform ?
Is is possible ?
And do any have a tutorial for this ?
Its just so great! Very well written