It has been an interesting week for iPhone developers. iPhone just released the developer preview of the iPhone OS 4, which has got features that are exciting to both developers and users. However, John Gruber discovered that Apple made a change to their iPhone SDK Licence Agreement with this release.
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).
This amendment has far-reaching effects. The effects are so powerful that the FUD surrounding it over-shadowed the excitement of the OS upgrade itself. There's no doubt that there's evilness in this amendment to the ToS. The question is what part of it is evil, and how should we react to it. Let's analyze this amendment, and see what it potentially means.
On APIs
Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
This seems reasonable to me. It's Apple's platform, and they expose a bunch of APIs, and they only want developers to use those APIs. However, it stinks of potential anti-trust cases. However, this is not what got people pissed off for, so let's skip past this statement.
On language of choice
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
This is plain stupid, and only serves to push developers away. Everyone knows that the choice of programming language hardly matters in any meaningful way, and what the developer is comfortable with is what s/he should ultimately use. This clause doesn't allow for that, and there's no good reason why it shouldn't. Just plain stupid.
This kills the soon-to-be-released CS5 Flash-to-iPhone compiler, the MonoTouch project which compiles C# and .Net to the iPhone, and the Unity3D project that let you program 3D games in C#.
However, also consider that without asking you for your source code, how can Apple guess which programming language you used for development? It's all compiled anyway. It just doesn't make sense. I don't see how Apple can enforce this. We'll have to see how this develops.
On compatibility layers
(e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
This is the big one, and is the reason most people are pissed off, because it's implications are far reaching.
Firstly, consider the case where I want to build an iPhone app using Ruby, and I use a library that has wrappers on top of the Objective-C APIs. This is like the point above, where I should be able to choose my language and program in it. And like I said above, there's no reason to restrict this, and it's stupid on Apple's part to do this.
The other case is that of compatibility layers, where I code to an API much like above, but the compiler is designed to cross-compile to multiple platforms, not just the iPhone. This is the big one, and is what makes the future of platforms like Titanium and PhoneGap unclear. This means that as a developer, I only need to write once and the environment let's me compile and run anywhere. As we all know the write-once-run-anywhere dream has eluded us all the time — Java, Air and Flash being great examples of it. A look at applications like Eclipse, Open Office, etc., and virtually anything developed using Flash, and you'll see that it feels nothing like a native application on all platforms. This is neither the fault of the language nor the compiler, but that of the platform APIs (like Swing in Java's case). The problem is that since the platform API, which serves as a compatibility layer
in these cases, tries to expose APIs that can work everywhere, they are forced to do a bad job of it.
Let me illustrate this with an example, to drive the point home. The Mac doesn't have a UI for combo-boxes, whereas both Windows and Linux do. What would a compatibility layer do in such a case? There are four possibilities:
- If the API makes it possible to use combo-boxes everywhere, it'll not feel native on the Mac, because the OS itself doesn't do these kinds of UIs. The platform will have to fake it.
- If it doesn't let you use combo-boxes anywhere, it'll seem less powerful on Windows for developers, and will provide a bad UX for users.
- It can choose to present completely custom UIs, which falls in neither camps, and hence fails.
- They could also say that you can use combo-boxes in Windows and not on the Mac, but that'll only make the programming experience horrible for developers.
So which approach is the least bad? Swing decides to compromise on UX. Flash goes the route of custom UIs.
An interesting case to consider is that of Google Chrome, which has done the absolute right thing. The core engine is C/C++, and UIs are coded separately for different OSs. However, this is clearly expensive to do, and only someone with Google's resources can pull it off.
Of course, there's also the possibility that Apple just wants to make it hard for developers to build apps that can run anywhere, by creating a lock-in. However, I don't think this is the case, because they are still allowing JS to run, and their browser is one of the best browsers ever that a developer can work with. This browser itself can be looked at as a compatibility layer that works across platforms. I've actually tried it — fairly complex applications built for the iPhone work just fine in Android-based touch phones with zero effort to port it. This is because when you develop for the iPhone browser, you are actually developing for Mobile WebKit, and has nothing to do with the iPhone Objective-C APIs per-se.
Aside: I've just negated my own point. I've criticized cross-compilers, and then said that the browser is a great environment to code because you are platform independent. However, I think that you should think different
(pun intended) about browsers. This is because the browser is a sandbox that runs the Internet
from the user's perspective, and it's expected that the UIs on web pages will be platform independent. That's not the case with native applications. Besides, the browser doesn't just run applications — they are also content distribution channels.
From the point of view of the UX of applications built using a cross-compiler compatibility layer, I sympathize with what Apple's done. Do I think such apps should be banned completely? I'm sitting on the fence on this one. I think the best thing to do would be to let the application fail in the market, rather than disallowing such applications outright. But then, I can see why Apple would ban it as well. Apple has always been a stickler for the UX of applications on their platforms. On the other hand however, they enforced this on the Mac OS by giving guidelines, not by disallowing such applications. So this thought is full of contradictions.
Then there's the case of the app store. The idea of a market place is awesome, but Apple's moderation is just stupid. Other issues apart (and there are several), it's a model that simply doesn't scale. Maybe Apple did this 3.3.1 thing just to ensure that they can moderate lesser apps and make their moderation generally easier to do? If that's the case, Apple is just reducing their problems and moving it to all their developers. Just another reason why Apple's moderation is stupid. Why Apple moderates is beyond me. No other platform that I know of does this, including Apple's own desktop OSs.
History repeats itself, sort of
There's a bigger concern I've got. Let me put it this way. I used to be a VB developer back in the day. When the Internet started becoming interesting, I found out that I could take my VB knowledge and port it to the web to build ASP programs. It was awesome, and I loved how Microsoft had made it easy for devs to move to the web as a platform. However, when the .Net framework was released, MS told developers like me that ASP was not cool anymore, and that we should choose either C# or VB.Net. VB.Net, for those who don't know, is nothing like VB. It's an entirely new language. Besides, MS seemed to put it's weight behind C#. Most developers were convinced that they should move to C#.
Not me. I was filled with FUD. I couldn't let a company decide what programming language I should use. What if I pick up C# and a couple of years later, just as I'm getting comfortable with it, they tell me that C# is not cool anymore? Am I shooting a moving target?
That was the time when I picked up my bags, and moved from the MS platform to open platforms. I picked up PHP because it's programming model resembled ASP, so the learning curve would be smooth. Of course, I still had to learn a new language, but at least this time it wasn't controlled by a company and I could use it just because there was community support. And PHP had (and still has) great community support. I had immunized myself from what companies have to say about my development tool chain. I was free!
In hindsight, this was the single most important decision I've taken that transformed my career. Not that I was any good at PHP. But the world of open platforms and open standards based development made me a better programmer.
Though the situation is not exactly the same in Apple's case, it's not too different. Here's a company screwing it's developers up because of what they think is the ideal vision for the platform. It's not a democratic decision — neither MS nor Apple consulted me when they were making this change. If I was now an Apple developer, I would hear alarm bells ringing, and would refuse to work in such a totalitarian environment.
But the iPhone is where my target demographic is!
Sure. I still think despite all of this that the iPhone is still a cool gadget, and users will continue to be attracted to it. And developers go where the users are. What's the point developing applications for platforms where there are no users! So, you want to build for the iPhone, but you don't want to build for the iPhone. How do you fix this?
The solution is simple. Move to an open platform. I'm not saying that you should stop building for the iPhone, and move to Android. That'd be stupid. I'm saying that you build for the browser, and serve both iPhone and Android users in one go. As a long-time web developer and currently exploring the mobile-WebKit browser, I can tell you that the mobile-WebKit browser is the best thing to happen to web development in a long time. It has imbibed standards support like no other browser has, even on desktop computers. HTML5 provides access to APIs that are mostly sufficient to build rich mobile applications. You've got excellent control on layout etc, since the CSS support is one of the best in the browser landscape. In fact, the browser in the latest phones is so good, I find it difficult to understand why I'd ever build a native application.
Here's a listing of some APIs that are available in the iPhone's and Android's browsers, that you probably didn't know existed. Yes, you can use all of these APIs today!
- APIs to get the users location using the GPS or cell-tower triangulation
- APIs to make the application work offline
- Local storage in the form of:
- Awesome drawing APIs and vector graphics APIs
Of course, there are cases where you need to build a native application. Like if you want access to the camera. Or if you want to use the user's contact list. Or access the accelerometer. I'd still go native for those kinds of applications. However, very soon, that's likely to change as well, with the upcoming Capture API and Contacts API that are being spec'd. And I'm sure WebKit will one of the first browsers to adopt it.
On the whole, there's very little reason now to build native applications for the iPhone. Do it only if you know what you are doing, and you absolutely need to. Ask yourself before you start if you absolutely must go native. You'll discover that in most cases you won't need to. The browser is good enough. And you'll have supported other touch-phones while you are at it, for free, at its very least. At best, you've supported the entire mobile browser landscape, though that's a hard one, and realistically speaking you will compromise on the user experience.
One last concern remains. What if Apple decides to somehow ban browser based applications? Technologically speaking, I don't see how they can do that without reducing the power of the browser itself. One of the reasons the iPhone took off was because it shipped with a real browser
. If they reduce the power of the browser, they reduce the usefulness of the phone itself. I don't see that happening. Secondly, the browser engine is actually developed independently of Apple — in fact Google contributes more to WebKit than Apple does. Unless Apple decides to revert to an older version of WebKit, or cherry-pick features from the public builds, they'll have to continue shipping the public builds of WebKit or feature-freeze on the current build. If anyone thinks Apple will (or can) control browser based applications, they're just plain wrong. The web is far too big for Apple to make such a move.
These are my thoughts. I'd be extremely interested in knowing what you think. Are you affected by this change? Are you going to move to the browser?
9 comments:
Update: Nice. Barely just made this post, and news has come in that Adobe just demo'd their Flash to Canvas export tool.
I expect this story to develop further over the next few days. But looks like going to the browser is the way forward so far!
After the initial outrage, there are two things that remain on my mind: disgust and fear.
Disgust, because Apple is treating developers like dirt. They will change the rules of the game whenever it suits them, regardless of how many devs they screw. In fact, they make M$ look good. That takes some doing.
Fear, because of the precedent that this sets if Apple is allowed to get away with it. What Apple has done with the app store is that it is playing middleman between developers and potential customers. Sure, you say, its their platform and they have the right to do whatever they want with it. As do Nokia, RIM, Microsoft, Google, who've all come out with their own app stores by now.
But, the thing is, computing is moving towards mobile devices in general. Do you want a future where, its not the market, but a select few companies which decide whether people get to use your sofware or not? Where these companies act as gatekeepers and months of your development effort is left to the whims and fancies of some random guy pissed off with his job? This is exactly what will happen if Apple is allowed to get away -- others like Microsoft and Nokia would want to join the party and we'll be left with a very closed world of mobile computing. Where would we be if the same thing had happened with the PC?
Given these issues, saying that a lot of people use iPhone so I'll create web apps *and* make sure they work well with the iPhone/iPad means that you are supporting this platform as much as Obj-C devs, IMO. You might like to think so, but the fact remains that, native apps are not going to die away any soon. They are more responsive, you get a consistent UI experience (mostly), and, well, javascript is just not the right hammer for every app out there. Things like graphics heavy games, dev tools, etc. won't move towards HTML/JS anytime soon.
Here's a little thought experiment:
* pick the top 20 iPhone apps
* can you create a web app version for each one of them? create web versions for as many of these apps as you can
* wait six months. do they give the native iPhone apps a run for their money?
* if they do become more successful than the native apps, do you think that Apple will sit pretty and not do something about the lost app store revenue?
I like this post.New York Trucking Companies
Why did the pandemic shut down the first game of the year - stillcasino
After the pandemic pandemic had lifted in 2020 and 2020, the pandemic closed in 2020 and 2021, starvegad and the pandemic 188bet began to ラッキーニッキー
Appreciate this share. It's effective! Septic Tank Pumping West Edmonton
Very helpful tips, thank you!
Awesome. Thanks for posting this. concrete construction companies San Antonio TX
If you're on the lookout for heavy equipment in Texas, you'll be delighted to explore the vast array of heavy equipment auctions available in the state. These auctions provide a unique platform for buyers to discover a wide range of machinery options, all in one convenient location. Whether you're in the market for construction equipment, agricultural machinery, or industrial tools, Texas auctions offer an extensive selection to cater to your specific needs.
When you participate in heavy equipment auctions in Texas, you'll have the opportunity to browse through a diverse inventory of machinery. From powerful excavators and versatile loaders to robust bulldozers and efficient cranes, these auctions showcase a variety of equipment options to suit different industries and projects. Moreover, the auctions feature both new and used machinery, allowing you to choose the best fit for your requirements and budget.
Post a Comment