REALbasic on iPhone Debate

The March/April 2010 edition of REALbasic Developer Magazine hit my inbox this morning.  Besides the normal BKeeney Briefs column Marc Zeedar and I have a spirited debate on whether or not REAL Software should devote existing resources to making REAL Studio work with iPhone apps.

Note the italics on ‘existing’.  While I think it would be a nifty idea, overall, I question the wisdom of diverting resources from an already small development team to a product that might be doable.  Is this a Mac OS X only product or is it cross-platform?  I seriously doubt that it will be cross-platform but perhaps I’m wrong.  The point is that there are a ton of issues to figure out and then the question then becomes, “What are we going to give up in the desktop versions while this is being developed?”

Other thoughts:  Apple makes a boatload of money from developers buying Mac hardware and this product has the potential to take that revenue away.  One could certainly argue that it has the potential to sell more iPhones/iPads/iPod touches because more applications will be available.  But Apple has 140,000-ish apps right now.  Would 10,000 more, or 100,000 more really mean anything to Apple?

It also has the potential of being a potential support issue for Apple.  Assume for a second they allow RS to make iPhone apps.  The RB framework has a bug (because that’s never happened), or Apple changes the SDK one day and doesn’t give RS advance notice (Apple is secretive, no?), and now tens of thousands of RB iPhone apps no longer work.  Will the developer, RS or Apple get the blame?  Apple.  Just like how Microsoft gets the blame for crappy drivers and crappy 3rd party apps made by bad developers, Apple would get the blame.  Apple guards the keys to their kingdom very closely because they want it to be associated with a classy, premium product that “just works”.

Anyway, you can read the debate between Marc and myself in the magazine.  My guess is you can figure out my viewpoint.   😛  Marc argues, the opposite.

My regular column talks about making your projects more Agile-ish without going full-bore in using the Agile process.  It’s not as hard as you think and your clients might really like it.

Your thoughts?

27 thoughts on “REALbasic on iPhone Debate

  1. Bob, I’m not an RB developer subscriber, but I am all in for iPhone development. I believe it’s essential for the future of the product. Here’s why:

    I have dozens of customer requests asking for an iPhone client for Virtual TimeClock. I suspect many other successful developers want to leverage a decade of in house RB skills rather than hiring/training an engineer to do xcode/objective C to support the iphone platform.

    This is entirely consistent with Real Studio’s focus, write once, deploy on all popular platforms. Mobile is no longer a niche market. It’s becoming another platform where our customers are expecting solutions.

  2. Something I’ve been looking in to lately is the Corona SDK. Its language is somewhat similar to what we’re used to, and appears to have pretty good support. While it is Mac only (for signing purposes, according to one of their team members in a response to a tweet I sent), it could potentially be what we’re all looking for.

    https://developer.anscamobile.com/

  3. My opinion is simply. Adding iPhone to RB is just a waste of money. RS can never keep up to date with Apples changes and they would need to support everything the OS offers to make your app feel native. And if RB is just a recompiler for Basic->Objective C in the background, I don’t get the benefit.
    Another thing is games like unity. They have an engine and just deploy it on a new device. Games do not use standard controls and need less integration. That’s okay.
    Third you can thing about time. They started with LLVM some time ago. I bet it’ll take till next year until this compiler change works. If they’d add an ARM support to it in 2012, do you think Apple still uses ARM for the iPhone in 2013 when maybe the platform layer is ready?
    RS has a lot of work in progress they want to finish and while everyone speaks about Apples sales in the iPhone/iPod category, you should better look on the Mac platform which is also growing.
    Just my 0.02 cents…

  4. If RS would make a fully supporten implementation (think – native look and feel on a platform!) I’d say “Go for it!”. It will be a huge waste of money and resourses but hey – it’s #1 in the Feedback system…
    I cannot even understand who got this crazy idea in the first place!!! The iPhone SDK is not open source and why would Apple even bother?!? Makes more sense to have RB compile for the Adobe Flex SDK that is at least open source….

  5. Exactly how big _is_ the iPhone market. From the outside it appears it must be far larger in the US than UK/Europe. For example statistics for mobile phone games download in the UK indicate about 400k for the iPhone compared to 600k for smartphones and 1.08m for “normal” mobiles. In UK/EU Nokia mobiles far outsell iPhone to date, and of course Nokia smartphones use Symbian.

    So assuming that RS can wave a magic wand and allow RB to compile for iPhones, what market potential actually exists in real numbers? And since they cannot build support using handwavium, how does the development resources needed to get into that market compare with the resource/market ratio of other mobile systems like Symbian or Android?

  6. @S-Copinger
    Presumably when we say ‘iPhone’ we’re also talking iPod touch and the iPad since they all use the same SDK. So how big is big?

    Well, it’s big, and growing. At the end of fiscal 2010 Q1, it was officially 42.482 million iPhones (per Wikipedia). As of Sept 2009 they had sold over 20 million iPod touches and one could presume that number to be *much* higher after the holiday season.

    The iPad is also, presumably, going to be a huge hit. I know plenty of folks that won’t hesitate to buy one because they’re already in the iPhone ecosystem. If you already own an iPhone/iPod Touch and have a bunch of apps, the iPad seems like a no-brainer because you can share apps.

    The other thought is that if you can compile for ARM, there’s nothing stopping you from compiling for Android or any one of a number of phones. You think Macintosh/Windows/Linux support is bad? Wait until they have to support umpteen variations of the Android.

    Anyway, I understand *why* it’s an attractive prospect. But I’m with you, ‘handwavium’ (love it!) isn’t going to make it happen overnight and I’m afraid of the side effects to the desktop version and if it can survive the time period to make it.

  7. Well, RS needs to use the tools Xcode provides for signatures and to have compiler, links and libraries. So you will still need the Xcode stuff installed, the $99 fee to get a signature and everythings runs only on a Mac. Also you won’t really reuse existing code, as the whole GUI concept is different. Not to mention that you need to learn all the new GUI stuff from Apple.
    And if you need to learn a framework, you can go directly to Cocoa Touch.

  8. Why on earth do they need to compile for ARM? Compile for C and use the Apple toolchain. Many people don’t realise that LLVM includes “a back-end which emits portable C code” – see http://llvm.org/.

  9. @Andy Dent
    There are parts of REALbasic which can’t be readily modeled in pure C (exceptions come to mind), which would have to be taken into account. Also, you can kiss those fast compile times goodbye with a scheme like that. Hmm, and debugging would suddenly become much harder too…

    It’s not a bad idea, but it’s also not a snap-of-the-fingers change, either. Honestly, targeting ARM would be easier.

  10. To a certain extent, I can understand the desire to develop iPhone applications in RB. It would certainly make iPhone development accessible to a broader audience, empowering just about anybody to create iPhone applications (whether that would be good w.r.t. the general quality level of available apps or not is another debate).

    On the other hand, I would see RS focused on what it is good at: cross-platform desktop applications (IMHO it’s not like all desktop applications will vanish within the next few years). I really think focus is the key here. Nobody is served by just another platform on which you can only access a minimum subset of the possibilities. And the more I think about it, the more I come to the conclusion that this is also an issue of using the best tool for the job at hand.

    I often hear/read the complaint that Objective-C/iPhone Development is hard. It is certainly true that it is not easy, but you can also learn it if you really want to. I had to do so for my current job: for the first few days I had a very hard time understanding things, despite my knowledge of other languages such as RB, Java, PHP. But it has been possible come up to acceptable speed within a couple of weeks. Of course, I am still learning a lot and do not fully understand every aspect of iPhone development and Objective-C, and I am not claiming that I can develop an iPhone app from start to finish, but I can help my collegues.

  11. The computing world is evolving. The web and handheld devices are becoming increasingly important. They are platforms just as the desktop OSs are platforms. We MUST evolve or we will die. And that “we” is both you and me.

    It’s that simple.

  12. @Geoff
    This is true, but would the more logical choice be a move toward a platform that all devices support, like the web? It would be much easier to use Yuma, build a little extra framework around it, and go in that direction than it would be to target even one mobile platform to run natively. That would save REAL money, and us in the long run.

  13. @Aaron Ballman If you are using LLVM to “target C” as a compiler for both RB and to recompile the C++ code which I assume still forms part of its core framework, then I think the point about things like exceptions goes away.

    I agree debugging is going to be massively difficult, whichever scheme is adopted. I”d almost be tempted to do a two-layer scheme where an “RB interpreter” was used for most debugging, separate from the deployment environment which requires full native compilation.

  14. Pingback: REALbasic, the iPhone and Valentina DB @ Valentina Dev Log

  15. Paradigma Software has had a Valentina Client for the iPhone for almost a year, and while its seen some use, I often feel that just having it has helped bring new customers to use Valentina DB (http://www.valentina-db.com) who have no intention of using Valentina for the iPhone.

    A lot of folks commenting know REAL Software – the company – very well. Maybe too well. Supporting the iPhone sounds like a monumental task, and you’ve been waiting a long, long time for Cocoa support and that’s likely come at some cost. You don’t want to go through that with iPhone support.

    But at the end of the day, a company closely associated with the Mac – and therefore Apple – must have an iPhone strategy, or they will see their customers move development to a tool that supports both. Runtime Revolution has already announced a mobile strategy for Runrev and in preparation for a mobile strategy. Unity, a popular 3D development system – dropped their basic product to free but charges a professional level of pricing for iPhone compatibility (they use Mono on desktops and generate Objective-C based projects for compilation to iPhone).

    So I have to agree with Geoff Perlman of REAL Software – REAL must have a significant iPhone strategy or they will not be able to evolve with the market.

    But at the end of the day, a company closely associated with the Mac – and therefore Apple – have to have an iPhone strategy, or they will see their customers move development to a tool that supports both.

  16. I’ll remind everyone that the question, as posed to me for the magazine article, was: Do you think RS should use *EXISTING* development resources to make REALbasic support the iPhone.

  17. “Do you think RS should use *EXISTING* development resources to make REALbasic support the iPhone.”

    My understanding of the latest REAL blog entry is that the forthcoming switch to using LLVM is that amongst its benefits is to provide a VM to native compiler for the iphone.
    Also, (and I’m guessing) having no longer to maintain the 2 backend compilers will free up some resources for other uses 🙂
    I’d like to read your take on the implications of the switch to the LLVM.

  18. I’ve built several real estate analytical apps in RB. Owing to the number of input fields, the “real estate” on the iPhone/iPod Touch is too small. On the iPad, however, we have the perfect platform for my apps. I am too old to learn the languages needed to reprogram my apps for the iPad but would like an easy way to migrate from standalone RB to iPad. That would be a home run for me.

  19. Lest anyone forget that Apple guards access to their kingdom very closely, I suggest you read the article at http://www.informationweek.com/news/software/linux/showArticle.jhtml?articleID=224000202.

    The relevant quote: “It would be a technical violation of the Apple SDK to [generate and sign an iPhone binary] on a Windows machine,…”

    I believe RS would have to jump through the same problems *if* they made iPhone support cross-platform. Since this is all mental gyrations at this point it doesn’t really matter.

  20. There’s no need to sign the app on a Windows machine. We would easily provide a service where the user could upload their code signing certificate and app to a Mac at REAL which would then sign the app via Apple’s code signing utility and then download it again. Others have solved this problem. The article also mentions running the iPhone SDK on a non Apple-branded machine. But a REAL Studio user would not be using the iPhone SDK at all. They would be using our framework so that’s not an issue either.

  21. @Geoff — are you intending for the iPhone offerings to mostly target the hobbyist market? I ask because there are some serious flaws I would worry about as a professional. Servers go down, companies disappear, etc — expecting me to rely on a third party for basic functionality any time I wish to release an application is a high risk. And telling me “well, just go buy a Mac if you’re worried about that” is an awfully expensive hidden cost, and doesn’t jive at all with REALbasic’s long history of allowing me to write code on one platform and run it on another.

  22. If REAL Software disappeared and REAL Studio wasn’t acquired by some other company, having to find access to a Mac so that you can install your certificate would be the least of your problems. The fact is, the code signing utility that Apple provides runs only on a Mac. I’m imagining that we could provide a Mac server as a convenience to Windows users. I would rather not have to do that but unfortunately, this is one issue that may not have a better, more feasible solution.

  23. It would be a useful addition to the Enterprise edition to allow someone to sign iPhone apps on others’ behalf. This could then become a consulting activity where you could find some other provider of the service rather than having to rely on RS running an inhouse server.

  24. Well, to sign you need your private developer key and the provision profile. I have for example 3 private keys for 3 different accounts and I need to choose the right one for each project to sign it correctly. But I’m not sure whether it is a good idea to upload those keys to a server somewhere. Does Apple allow/deny that? And why should RS not simply say: iPhone development is Mac only and please install Xcode first?

  25. New today is this new except from the iPhone 4.0 SDK:

    3.3.1 — 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).

    Here, they are explicitly saying what language is allowed! Wow. That seems awful restrictive.

Comments are closed.