REALbasic for iPhone Revisited

The iPhone 4.0 SDK was announced today by Apple.  It has a ton of new features and most are welcome.  It’s not all good news, however.  Stuck in section 3.1.1 of the new iPhone Developer Program License Agreement is the following:

Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Wow.  I find this to be simply, and utterly, the most arrogant thing that Apple has done in my many years of being an Apple fan.  I find this to be distasteful in the extreme.  Words can’t describe how angry/disappointed I am in the “Think Different” company.

Now lets talk about the debate we had a while back of REALbasic making apps for the iPhone.  In my debate with Marc Zeedar for March/April 2010 issue of REALbasic Developer Magazine I said this:

An iPhone version depends on the willingness of Apple to let REAL Software play in their court. I have my doubts that Apple would do that simply because all of those 140,000+ iPhone applications they’re touting were developed on a Mac. Letting go of those hardware sales is not in Apple’s best interest economically. Not only that, but letting RS create iPhone apps now makes Apple dependent upon a third-party to issue bug fixes in the framework and be up-to-date whenever a new SDK is released.

I think today’s new license agreement proves my point.  Apple is going to control everything and if you don’t want to learn Objective-C and use XCode and CocoaTouch too bad for you.  Apple controls the entire ecosystem and they are not going to let anyone play in their court.

Much will be said in the upcoming weeks and months about the new license agreement.  The anti-Apple folks will use this to bludgeon the advancement of the iPhone and iPad into the corporate environments.  What will pro-Apple folks do?  Shut-up and start learning xCode and Objective-C because there’s not much to defend.

Will it always be this way?  I don’t know.  But I do know that nothing will change unless Apple starts losing money and by all accounts that’s not going to happen any time soon.

12 thoughts on “REALbasic for iPhone Revisited

  1. I’ve personally been affected by this as I have spent some time using MonoTouch. While the early versions of my apps were written in objective-c and it’s a fine solution, monotouch gave me .NET-class SOAP support and memory management. My rate of productivity likely quadrupled – and I was still doing it on a Mac and conforming to all the rules. Now, I’m considering dropping my apps together despite being profitable on principle alone. Clever solutions and new innovative ideas/ways to create for a platform are a great thing and if Apple doesn’t recognize that, I’m not sure why apps exist at all.

  2. So, it looks like Apple are giving up any effort to become a “dominant party” in mobiles in Europe. If they did, it’s pretty likely that the EU anti-monopoly legislation would come down hard on this restriction; at the moment they have about 25% smartphone market share (Nokia have near 40%) so not an issue, but in the future…

  3. Apple does not respond well to threats. They might just pull everything like they did in France when the government there tried to force them to open iTunes to other mp3 players.

    I have my own doubts about whether anti-monopoly would even apply here.

    Apple could just as easily say “sure build with whatever you want” and then just not approve any apps not built with XCode. It would not surprise me if they have ways to tell and if these apps don’t interact well with others then Apple would still be able to choke them off before they’d be in the App store.

    Maybe this restriction will change in the future – hard to know for sure.
    Have to wait and see.

    It would be nice to know what the real motivation for this particular change is.

  4. The last item that I read stated that part of the reason why non-Cocoa development tools could be a problem is the interaction of the programming language with Apple’s multitasking in iPhone 4.0. Since REALbasic (and Flash?) does not have full multitasking, this may be a problem.

    The other possible reason is that Apple does not want third-party libraries to dictate the APIs and rate of development of the iPhone OS. I can understand this, too. Why should Flash’s or RB’s APIs hold back what parts of the OS can be accessed or when changes can be introduced without breaking these tools?

    It might help if RB’s front end could cross-compile to Obj-C/Cocoa (which would then be compiled and linked by XCode) and provide access to the full Cocoa libraries. Objective-Basic, developed by a one-man company, already does this.

  5. Straight from the horse’s mouth: ‘We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.’

    What a jackass.

  6. Scott Steinman :
    The last item that I read stated that part of the reason why non-Cocoa development tools could be a problem is the interaction of the programming language with Apple’s multitasking in iPhone 4.0. Since REALbasic (and Flash?) does not have full multitasking, this may be a problem.

    I think this is close to the mark since I’ve heard the restriction will not be enforced until version 4.0; but I also think that it relates a good deal to the automated testing Apple will inevitably have to do on a far grander scale. They’ll likely want to validate that the apps using the multiprocessing APIs do indeed play nice, perform well, and suck power less. The sheer volume they have to process alone in new apps — much less a rewrite or update of every single iPhone app for the iPad and then version 4.0 — suggests they are going to have an ever increasing reliance on better automated testing and evaluation. It’s a heck of a lot harder if they have to validate code calls coming in from a dozen different “unsupported” development environments that each have their own implementation conventions and intermediate representation formats.

  7. Couple of good links to read through:

    http://www.devwhy.com/blog/2010/4/12/its-all-about-the-framework.html

    http://37signals.com/svn/posts/2273-five-rational-arguments-against-apples-331-policy

    We” (developers and techies) keep thinking of the iPhone/iPad as a computer and we’re accustomed to using whatever development environments we choose. But it is not a computer. It’s more like (but not exactly) the Nintendo DS or PlayStation Portable. Their hardware and software is locked down pretty hard too.

    To the end user, the iPhone “just works” which is synonymous with “quality” or “not Windows”. Letting 3rd party dev environments onto the iPhone risks that quality. Once Apple loses the ‘quality’ it’s only downhill from there.

  8. @Aaron Ballman
    Apparently a good kind of jackass since Apple’s market share has climbed dramatically and their stock has gone from $7 to > $230 and Apple’s total market cap is nearly that of MS 🙂

  9. I enjoyed this one entitled “Apple’s Wager” at http://arstechnica.com/staff/fatbits/2010/04/apples-wager.ars

    I think if you look at it *purely* from Apple’s viewpoint, the licensing change makes a lot of sense. Allowing 3rd party frameworks on to the device means they have to slow down and make sure all the vendors are onboard before they do an update. This way, they only have to update one tool and everyone is up to date at once (more or less) and that can happen quickly. Multiple times per year if need be.

    Apple is in a race with all the other mobile device manufacturers. Android will continue to get better. Same with RIM, Palm (if they’re still around, that is) and Windows (assuming they get their heads out of their rear end). The stakes are enormous and so are the risks.

    Think about this way. The paid analysts have been consistently wrong in their predictions for how many devices Apple has sold. Wrong as in way UNDER – not over. Apple is blowing away Wall Street analysts – consistently. For the first time in my memory, Apple is going after market share and doing it without sacrificing their sacred profit margins.

    I know a lot of my fellow RB developers are hitching their wagons up to Apple and the iPhone. One, they are generally Apple users and enthusiasts themselves and have been for a long time. And two, “There’s gold in them there hills!” Mobile apps represent a growth area and there’s a huge demand for developers right now.

  10. @Norman Palardy

    Yes, I have tried it, and you’ve underestimated it — the first iteration of it (before the author decided to totally rewrite it) _was_ marginally usable. 😉

    The new version is not there yet, and development is slow. I’m still curious to see how it will turn out.

  11. The restriction on which language an app was originally written in, strikes me as damaging to consumers and developers–and probably harmful to Apple in the long run. I see the Justice Department is taking a look at that requirement, which is good as that approach makes me very uncomfortable. What about a TV set with a license restriction that you could only watch specified channels? Or a car purchase agreement that specified you could only purchase gasoline from Shell or BP? It seems that which programs I run and even more particularly, which language those programs are written in, is not the business of the hardware manufacturer. I think there are serious anti-trust concerns with this one.

Comments are closed.