SAP from the Apple tree

This post is predominantly for those people in the SAP development community who lament the news that Apple has decided that with iPhone OS 4 any 3rd party dev environments are kicked off the popular mobile platform.

If you’re an accomplished iPhone developer who largely focussed on Adobe’s Flash-To-iPhone compiler or tools such as MonoTouch (both of which I do not know or have used, by the way), then I can actually understand your anger.

However, if you are a developer who lives and breathes the SAP ecosystem -and ABAP in particular- then this whole epipsode must sound to you like a sequel of “Back to the Future”. Apple’s move aims to create a development platform which is dominated by the one and only language Apple (who actually developed the platform’s hardware)  sees fit – Objective-C. Parallels to SAP’s own proprietary language ABAP are not out of place here.

I’ve recently dabbled a little with iPhone SDK and even though ABAP and Objective-C are not very similar languages by and stretch of the imagination, what they do have in common is that their respective “inventors” push these languages for reasons of stability (a strength of both SAP’s ABAP stack as well as the iPhone OS), reliability and performance.

For years now, SAP’s ecosystem has been mainly hailed for its rigid design under the bonnet, the bulletproof-ness, the stability. At the end of the day, vast numbers of global businesses rely on SAP’s technology day in day out. ABAP, love it or loathe it, plays a central part in that. (It also plays a central part in which future path for SAP to turn towards and innovate the core, but that’s another topic).

Maybe it’s because I’ve been using stable Macs for 15+ years now and been part of SAP’s ecosystem for many moons, but why is it so hard to understand that Apple is trying to provide a stable and reliable platform for iPhone, running on hardware Apple has developed itself? I’d wager that the same people who now complain about the locked-down dev platform would also be the first who would complain about crashing iPhone apps had the device not been so tighly regulated.

10 thoughts on “SAP from the Apple tree

  1. Jan Penninkhof

    April 9, 2010 at 10:26am

    It’s always a matter on how you interpret things, but here’s my view on this:

    If you look at SAP, you could see it as a bunch of business rules with a bunch of APIs on top (RFCs, IDOC then BAPIs, now web-services). SAP is keeping the APIs and business logic proprietary and I think this is understandable in a way (although the open-source movement may not agree). However, you are free to connect to those APIs in the way you want to and with the programming language you prefer. SAP has even facilitated this, by providing RFC toolkits for several platforms and programming languages and now even provides a full-fledged middleware layer. I have taken full advantage of this in the past and have written several visual basic, COM, IDOC,PHP, Java and Flex apps that are connecting to SAP.

    Forcing developers to only connect to their APIs if they implement their app using C/C++ /Objective C or Webkit JS is in my opinion completely different from what SAP is doing. If SAP or Microsoft would limit the freedom to mix and match your own platform together like Apple does, they might hear from Neelie Kroes very soon.

  2. Michael Koch

    April 9, 2010 at 10:39am

    Hi Jan

    I think the basic difference of what you’re describing here is the fact that SAP’s software is for access to a server or central instance, allowing this via defined APIs (which have mostly ABAP under the bonnet). In contrast, iPhone is a mobile end-user client device.

    Also don’t forget that there are still the web apps that can be developed (in .net for example) for iPhone’s Safari.

    But you can’t get away from the fact that both companies use proprietary languages or dev platforms to achieve stability, reliability and maximum performance. And that’s not a bad thing.

  3. Darren Hague

    April 9, 2010 at 10:48am

    One word: Java

    SAP gives you a vendor-supported open-standard “write once, run anywhere” option for development. Apple, not so much.

  4. Michael Koch

    April 9, 2010 at 11:08am


    My point was more general about the strengths of a proprietary language in SAP’s and Apple’s case.

    And: If you invest $$$ into the development of a hardware platform, do you want to see it becoming unstable by 3rd party APIs and pre-compilers that generate code you can’t control? I wouldn’t. If I would develop something like this for ABAP then the first thing I need to do is become a SAP partner, which costs a tidy sum (if SAP would let me become a partner for that reason in the first place). Openness?

  5. Mrinal Wadhwa

    April 9, 2010 at 11:42am


    Platforms are based on the premise that third-partys will build on it .. X platform exposes an Interface (an API they control) and then third partys talk to the platform via the api … a cross compiled app or a hand coded app both talk via the same interface, both can be just same amount unstable.Compilers are just translators.

    Also, what Apple is doing can get pretty nasty very quick, so Apple says if you want to build for our platform use C, C++ or Objective-C .. microsoft says C,C++, C# … that’s the two main platforms …. what happens to all the other programming languages in the world … dead … that includes ABAP, JAVA, Python and all of these … dead … since all of them translate to (in the best case) machine assembly (who’s platform is that, Intel’s?) .. you see ?

  6. VJ

    April 9, 2010 at 1:51pm

    I think Apple is way too popular in the market to get hit by this policy. From an end user perspective, I don’t care about the technology – and as long as I am willing to spend money on Apple, developers will have an incentive in writing code that sells, even if they have to do it in COBOL again.

  7. Ethan Jewett

    April 11, 2010 at 4:00pm

    @Mrinal Wadhwa

    My reading of the policy is that if a third-party toolkit spits out Objective-C which is then compiled using the iPhone developer SDK, then this is allowed. I fail to see what the difference between this type of code and a hand-coded application is.

    On the other hand, compiling directly to the iPhone OS binary format (which I am assuming is what the CS5 Flash for iPhone packager does) seems to no longer be allowed under section 3.3.1 of the developer program agreement.

    I’m not terribly surprised by this. My understanding is that the Objective-C/C/C++ interfaces are the only public APIs that Apple has made available. I think the comparison to the SAP situation is apt. Does SAP allow partners to distribute ABAP byte-code extensions to its applications? How about extensions that call non-public APIs? Yes, on the the Java side SAP has exposed J2EE interfaces that allow for a lot of re-usability, but do they allow linking to non-public Java APIs in the SAP Portal? I doubt these types of development approaches would be good business in the SAP world any more than the Apple world.

    Obviously this is bad news for a lot of developers and for language diversity, as you’ve pointed out. On the other hand, the competing open platforms are all pretty sorry alternatives. It’s tough for Adobe to argue that they are being wrongly locked out when they have yet to deliver a performant (from both a UI and battery perspective) flash solution for a mobile platform. Similarly, it’s tough for open-ness advocates (of which I certainly count myself one) to fairly criticize Apple from the open-ness perspective when the community has as yet failed to deliver a compelling mobile experience based on open software. Android is getting there, and I eagerly await an Android device that I prefer to the current model of whatever Apple is offering.

  8. Mrinal Wadhwa

    April 11, 2010 at 4:43pm

    @Ethan Jewett

    The CS5 compiler uses LLVM with an Actionscript3 frontend and an ARM assembly backend, so it takes in AS3 and spits out ARM assembly.

    I kinda agree with your reasoning Ethan, except its very worrying to think of what will happen if more platform vendors start taking this approach.

  9. Pixelbase » This Week in SAP

    April 21, 2010 at 10:27pm

    […] also been some inspired and passionate debating going on my recent blog entitled “SAP from the Apple tree“. OK, it’s a shameless plug, but I don’t […]

Comments are closed.