Apple's iPad

[Wiglaf]

I'm troubled you cannot see the contradiction between the last two paragraphs of what you wrote. Either you need to worry about upscaling it or you don't. You can't decide.

The simple reality, WHICH I HAVE VERIFIED BY LOOKING, is that the iPad has to magnify iPhone OS apps designed for the lower resolution. Many Android apps are the same way. (I don't know what yours is but it's apparently a ****ing list of ****ing telephone numbers, which might explain the ease of upscaling it).

[Asher]

I'm troubled you cannot see the contradiction between the last two paragraphs of what you wrote. Either you need to worry about upscaling it or you don't. You can't decide.

The simple reality, WHICH I HAVE VERIFIED BY LOOKING, is that the iPad has to magnify iPhone OS apps designed for the lower resolution. Many Android apps are the same way. (I don't know what yours is but it's apparently a ****ing list of ****ing telephone numbers, which might explain the ease of upscaling it).

This whole post is 100% wrong. No Android apps magnify unless they were designed with pixel-specific layouts, which 99% are not (and you're explicitly told not to).

[Wiglaf]

Look the fact remains that I have no idea what I am talking about but if you look at how iPhone popularized smartphones, one thing is clear: no one would be buying Android apps if apple hadn't led the way, and if apple hadn't led the way, there's no way Google developers would have put together such an elegant solution this quickly, much less one with touch screens.

[Wiglaf]

From Joe Hewitt, Facebook iPhone developer. I THINK WE CAN TAKE HIS WORD ON THIS.

"The one thing that makes an iPhone/iPad app ?closed? is that it lives in a sandbox, which means it can?t just read and write willy-nilly to the file system, access hardware, or interfere with other apps. In my mind, this is one of the best features of the OS. It makes native apps more like web apps, which are similarly sandboxed, and therefore much more secure. On Macs and PCs, you have to re-install the OS every couple years or so just to undo the damage done by apps, but iPhone OS is completely immune to this."

[Asher]

What he says is 100% true of Android, WebOS, and Windows Phone also.

Not sure what your point is. Or his, for that matter, since his quote is out of context. Sounds like he's comparing mobile app development to the PC/Mac, which are very different paradigms.

[Wiglaf]

iPhone came first. That is all.

[Hauldren Collider]

iPhone came first. That is all.

You know that's a retarded argument, right? The Ford Motel T came before my Honda Accord but I'll pass on driving the former, thanks.

[Asher]

iPhone came first. That is all.

RIM adopted that application model long before Apple did.

Technically speaking, it's also the app model used on the Xbox and Xbox 360.

[DirtyMartini]

But just think of all the octogenarian booty you could pull.

x-post

[Asher]

http://arstechnica.com/apple/news/2010/04/steve-jobs-weighs-on-iphone-os-dev-controversy.ars

A brief assessment of Jobs's iPhone OS defense
By Peter Bright | Last updated about 7 hours ago

On Friday, we wrote about the changes Apple is making to the terms and conditions that it requires from iPhone, iPod Touch, and iPad developers before they can write software for these platforms. The new terms include a clause that prohibits a wide range of third-party toolkits and frameworks that offer developers benefits such as quicker, more robust application development and instant access to complex functionality like 3D game engines.

We believe the targets of this change to be, in particular, Adobe and Google's Android. Adobe is imminently releasing a new version of Flash that will, among other things, be able to produce iPhone applications. The new terms prohibit the use of such tools. Android is hurt because many of these frameworks facilitate cross-platform software development. As the smaller platform, Android benefits from the use of toolkits that allow developers to target the iPhone and then rapidly, and at low cost, migrate to Android.

Over the weekend, it appears that Steve Jobs weighed in on the issue. Jobs referenced John Gruber's rationale for the changes. He then, if the e-mails are authentic, clarified Apple's position, claiming that intermediate layers between developers and the platform have two results: they result in "sub-standard apps" and they hinder the "progress of the platform."

Let's take a look at each claim.
Standards

The first argument remains unconvincing to us for empirical reasons; just look at the App store! There are many excellent applications for iPhone that use the now-restricted frameworks (for example, the enjoyable and well-received games Colorbind, Battle Bears: Zombies, and Zombieville USA all use the Unity3D framework), while many sub-standard ones that do not (see: every fart application, ever). The use of frameworks is orthogonal to quality.

In fact, some of the very applications that Jobs demonstrated at the Apple event appear to use techniques that are now forbidden—Tap Tap Revenge makes use of Lua scripting, for instance. One thing shown off during this demonstration was how the game interacted with iPhone OS 4's multitasking support; this has significance because some commentators have speculated that the framework ban is somehow due to an inability of programs using these toolkits to support multitasking. Clearly, that is not the case.

If an application is good enough for Apple to highlight on-stage, it seems disingenuous to suggest that the app is sub-standard. If high-quality applications are what Apple is after, then that is what Apple should insist on; native code is no promise of quality.
Quality

The second claim might initially seem more sound. It's true that typical frameworks do not provide access to every single feature of the underlying operating system. This may not be universally true (I believe that MonoTouch, allowing C# development on the iPhone, offers extremely broad support for iPhone OS's APIs), but it's a common enough occurrence. As such, it's certainly the case that users of a particular framework might be cut off from some new platform feature that native coders would have access to, and that framework users are therefore restricted to a particular subset of the platform's capabilities. This in turn has the potential to damage uptake of new features.

But this claim also feels unconvincing when considered in more detail. Developers generally make their choice of framework with their eyes open. Developers already balance ease-of-use, time-to-market, and similar concerns against the level of access to the full operating system, and the result of this evaluation might lead to picking a toolkit that prevents access to certain platform features.

So what? This is nothing new. iPhone OS provides a huge range of APIs (a range that grows larger with each new release), and developers already make decisions about which APIs to use and which to ignore. No program uses every single API, nor should it.

The damage done to the platform by having, say, a games toolkit that cannot access the new iPhone OS 4 calendar API is negligible; developers writing games will almost certainly ignore the calendar API anyway. Making those same developers use native code just makes their job that much harder. On its own, it does little to ensure greater use of platform features.

Further, if Apple adds new, useful APIs that a broad set of developers wish to use, the developers of third-party toolkits and frameworks will surely respond to this demand by extending their frameworks to provide this access. If this doesn't happen, and a new API is left inaccessible, then perhaps it is not so much a flaw of the use of such toolkits, but rather an indication that the new capabilities are of minority interest.

This argument can also work in the other direction. The developers of the toolkits might very well have specialized expertise—expertise that users of the toolkit lack. Consider, for example, the Unity3D framework. The people writing Unity3D understand 3D graphics, physics engines, and so on, and it's quite plausible that they understand these things better than many users of their framework. As such, the Unity3D developers are in a position to expertly evaluate—and integrate—new features that Apple has added, such as the new hardware-accelerated mathematical operations. If left up to the individual game developers, however, this integration might not happen due to lack of expertise and resources.

This is not far-fetched; the use of this kind of framework is endemic in the world of console gaming. It enables game developers (whose expertise is typically creating compelling games rather than, say, maximizing performance of the PlayStation 3's Cell processor) to make better games that wring out more of the performance and capabilities of the underlying platform than would be the case if they had to start from scratch.

As such, well-written frameworks, far from reducing the level of uptake of platform features, can actually increase it.

There may also be a concern that if developers do want to use features that are not offered in their toolkits then they face a large task ahead: porting to native code (or perhaps to some other toolkit) just to escape the confines of the toolkit they are using, and so Apple wants to avoid this kind of lock-in (instead locking them in to Objective-C, of course).
Lessons from history

Such a problem has concerned Apple in the past, when many developers used Metrowerks' PowerPlant development environment to write "Classic" Mac OS software. When Apple subsequently introduced the CarbonLib transition framework to aid in porting to Mac OS X, these developers were then trapped, facing substantial costs to migrate their code.

This is certainly something that developers need to be aware of, but native code is no panacea in this regard. The provisioning of new platform APIs still requires developers to learn these APIs and then integrate them into their pre-existing programs, and this integration can have substantial consequences.

Programs might have to be radically restructured or rewritten to make use of new platform features (for example, breaking down complex tasks into individual pieces so that they can be used with Grand Central Dispatch, or transforming their data structures to be used with SIMD), and the inertia of these existing codebases is itself an impediment to the progress of the platform.

It's also a little peculiar to imply that these porting costs only exist when third-party frameworks are used. Apple is in the process of killing off the Carbon library on Mac OS X (no new features are being added to Carbon, and its 64-bit version was killed off unexpectedly, even though it was substantially complete), forcing developers to suffer an expensive migration to Cocoa. Developers had to undergo an expensive and lengthy porting operation in spite of using a first-party, native API.

Any time you have a legacy codebase, you are at risk of developers avoiding new features because they require too much development effort to add. Third-party frameworks do not create this problem; they are merely victims of it, just as native programs are.

The new 3.3.1 terms tie developers' hands, yet do nothing to ensure that applications are high quality or that platform features are exploited by software developers. In our view, the targets remain Adobe and Android, and everyone—except perhaps Apple—still loses.

[Fake Boris]

The iPad is a step in the right direction, but Apple is going to ruin it with their ****ty attitude. Working on a desk with a pen, or sitting on a couch with something that feels like a book is much more comfortable. Very few reviews have pointed that out. AnandTech has, and has gotten plenty of flack in the comments from people convinced that this kind of device (in general) must be useless.

Any postgrad student desperately wants a light and thin device that will let him download any book or article he needs, annotate them with a stylus, and have those notes integrated in a database that offers smart queries, tags, etc. (Handwriting recognition is of course necessary). You are often reading stuff in several different languages. Embedded dictionaries and grammars are incredibly useful. When you stumble upon a difficult passage, you want to write down possible interpretations. You want to draw brackets, lines, arrows, etc. And need I repeat myself? You want these things automatically indexed in a database.

It's also a nice note-taking device, especially for science/math students. The ability to draw is crucial. Record the lecture and bookmark it for later hearing if you missed a sentence or didn't understand something.

It could be totally useful too for profs who need to get outside of their PowerPoint presentation to answer an unexpected question. Especially in a large room where everyone can't see the chalkboard properly.

I can see incredible potential in academic use. The problem is it's not happening on Apple's platform. You need open standards like WiFi enabled projectors and stuff like that. It could happen more easily on HP's Windows 7 device; but HP is not likely to market it and push it properly.

Basically the possibilities are limitless. It could give board games a second coming; imagine everyone playing Diplomacy or head-to-head Civ6 on their tablets, with the main map displayed on the big-screen TV. And yes, the form factor and battery life makes it different than sitting around a desk with your laptops.

I'm just afraid Apple is going to screw a potentially awesome product with vendor lock-in and crappy developper support.

[Asher]

The iPad is a step in the right direction, but Apple is going to ruin it with their ****ty attitude. Working on a desk with a pen, or sitting on a couch with something that feels like a book is much more comfortable. Very few reviews have pointed that out. AnandTech has, and has gotten plenty of flack in the comments from people convinced that this kind of device (in general) must be useless.

Any postgrad student desperately wants a light and thin device that will let him download any book or article he needs, annotate them with a stylus, and have those notes integrated in a database that offers smart queries, tags, etc. (Handwriting recognition is of course necessary). You are often reading stuff in several different languages. Embedded dictionaries and grammars are incredibly useful. When you stumble upon a difficult passage, you want to write down possible interpretations. You want to draw brackets, lines, arrows, etc. And need I repeat myself? You want these things automatically indexed in a database.

It's also a nice note-taking device, especially for science/math students. The ability to draw is crucial. Record the lecture and bookmark it for later hearing if you missed a sentence or didn't understand something.

It could be totally useful too for profs who need to get outside of their PowerPoint presentation to answer an unexpected question. Especially in a large room where everyone can't see the chalkboard properly.

You want an HP Slate or a MS Courier tablet then, not the iPad. But you're right, they won't market it properly.

[MikeH]

Current Thread Score:

Asher 167 - 0 Wiglaf

[Wiglaf]

You're an idiot. Note that Asher's claim that "RIM and Xbox did it first" is particularly galling because neither had a touche screen, or thought to implement it with a touche screen.

[Asher]

But you must admit, a Blackberry is a great douche screen.