Steve Jobs lays out Apple’s position. There’s really nothing new here, but it’s very clearly written and without too much spin. It’s odd that he doesn’t count Microsoft as a major Mac developer, though.
Archive for April 2010
Someone involved with this truly believed that enough people want to see even more of these incredibly relevant ads on the blogs they’re trying to read to make it worth the overhead of being in one of the most widespread interfaces on the internet.
MonoTouch brings the C# language and the core of .NET to the iPhone, but does nothing to provide a cross-platform UI experience or for that matter any sort of mobile device cross-platform APIs.
We bring the C# language, garbage collection, a type safe system that help reduce errors, make programmers happier and more productive on the iPhone while getting access to every single iPhoneOS API that they want to.
We have also been able to expose new APIs that Apple has exposed in record time thanks to the fact that we are not really an abstraction layer over the iPhoneOS, but merely a compiler that talks to the native APIs.
BBEdit 9.5 is a great update that adds an inline live search field (which I control using the Emacs bindings and dismiss using Esc), some insane AppleScript hooks, and archive browsing. Projects are better at viewing unknown file types and at remembering the settings for invisible files. I also like that it’s better at preserving the scroll position when multiple applications are editing the same file. Transmit 4.0 was also released today, and though its product page is very attractive (and I’ve upgraded), I nonetheless prefer the Bare Bones way of publishing an extensive (and bookmarkable) list of release notes, with enough detail that I can understand what the changes were just from reading.
What this does, when enabled, is to cause GDB to only run the current thread when you click the “Continue” button or use the “continue” command from the GDB console, rather than running all threads at once. To enable this behavior, you can simply type “set scheduler-locking on” on the console.
Louis Gerbarg on Core Location:
In iPhone OS 4.0 this is being greatly improved, so much so that the improvements were demoed in the keynote. In 4.0 there will be a status bar indicating that an app has recently used CoreLocation, it will be possible to look at the list apps to see what has used your location in the las day, and turn on and off their access. All of this works without changes to the existing APIs, so all existing apps the CoreLocation will be effected, resulting in much better security of the user's location information, and the ability to notice and identify if something is using the data without your consent.
and Address Book:
By exposing the address book database in this way not only has Apple introduced a way for applications to read all of the address book data without going through the AddressBook API, they have also exposed an attack vector for applications to insert poisoned address data that can be synced back to other device, or even attack other applications inside their own sandboxes.
It’s odd that applications can’t directly share files with one another, but yet any application can read and write to the address book (and transmit it over the network), with no audit trail. On the Mac, I am at least somewhat protected by fine-grained backups and Little Snitch.
The other day I went hunting through the App Store hoping to find a nice clock for the iPad that I could turn on while it was sitting on my desk. To my surprise, there really wasn’t anything that appealed to me. There are a handful of really nice digital clocks, but I prefer analog. And the iPad’s size feels just right for a nice big clock face.
So he built one, and Apple rejected it because he hadn’t mucked it up with extraneous features (via Macworld).
This reference describes the Video Decode Acceleration framework available on Mac OS X 10.6.3 and later […] providing low-level access to the H.264 decoding capabilities of compatible GPUs such as the NVIDIA GeForce 9400M, GeForce 320M or GeForce GT 330M. It is intended for use by advanced developers who specifically need hardware accelerated decode of video frames.
Looks like this was provided so Adobe could make Flash more efficient.
Rouse is an attempt to create a new Mac OS X web browser that steals the best bits from OmniWeb for its user interface, adds some well-needed hooks to the interior to customize rendering and loading, and otherwise stays away from scope creep as far as possible. It is an open source project doing the sort of thing that open source projects have proven to be enormously successful at.
If it is Apple’s policy not to allow any political satire in the App Store, that’s terrible. If that’s not Apple’s policy, and some individual App Store reviewer rejected Fiore’s app mistakenly, that’s terrible. Either way, something terrible is going on. But worse than anything related to this specific case is the bigger picture: we don’t know.
Ok, I have an Intel X-25M 160 GB SSD coming and I’m on a VERY GEEKY mood…so I decided to poke around a little on what could be done to tweak Mac OS X in order to, at least minimize the write amplification problem and also optimize the space used—yes you know the €/MB ratio is high on SSDs. Most of these tweaks, besides providing for a longer lifespan for SSD disks, should improve overall system performance even on an non SSD disk.
He disables file access times and hibernate mode, and sets Xcode to build onto a RAM disk.
The new way is to rethink the fundamental deal for processes. In the old model, processes that have already been launched get priority — once running, they stay running. In the new model, the user’s intentions get priority. You press the home button, you’re going to see the home screen in a moment, whether the app that was running was ready to be closed or not. If you want to open another app, it’s going to open immediately, even if the system has to pull the plug on an app in the background to free enough RAM.
The iPad application, within five days, made us more money than the iPhone application has in its existence over the last six months or something. And it’s only priced double, $9.99 versus $4.99. So, that says a few things. One, I think it’s a better application, our application on the iPad. And being there on day one is huge, since everyone’s looking for apps. But, yeah, even with a much smaller user base so far, it’s just done so well.
NetNewsWire on the Mac is great, but I always found the iPhone version disappointing. This is probably not through any fault of Simmons’. It was just too slow and cramped on that hardware. On the iPad, though, it’s plenty fast and seems to fit the screen size well. The Mac version is more efficient for processing and skimming—the wider list view, keyboard shortcuts, and tabs are important—but the iPad version is certainly comfortable to use, especially for reading. I haven’t quite worked out when to use NetNewsWire vs. Instapaper, though. The latter is even better for reading, but of course I have to add pages to it manually.
Cumulatively, these actions represent a huge bet placed by Apple. The proposition is this: Apple is betting it can grow its platform fast enough, using any means necessary, that developers will stick around despite all the hardships and shoddy treatment. Each time it chooses to do what it thinks is best for the future of the iPhone OS platform instead of what will please developers, Apple is pushing more chips into the pot.
The win scenario is big: Apple as the dominant player in the most important new technology market. Microsoft-level dominance. But the flip-side is terrible—though I can see how it may have snuck up on Apple.
Unsurprisingly, the incentives for Apple and developers are not fully aligned. Larger developers will write for all the major platforms, regardless. For smaller developers, it matters little whether Apple achieves Microsoft-level dominance. They can be successful without a home run. Provided Apple continues to make a good product, the iPhone is likely to always have more marketshare than the Mac has enjoyed over the past 25 years. On the other hand, smaller developers could be in big trouble if they get banned from the App Store, or stuck in limbo. They’d probably be happy to trade some potential iPhone OS marketshare in return for certainty that if they follow the rules and spend the time and money to develop a product, Apple will let them sell it.
It’s hard to build a business on a platform where you feel like you cannot trust the men in power. If they can take down Adobe a few days before the launch of their flagship product, what hope do smaller players hold?
Here’s what would be outlawed for future iPhone development with this new SDK agreement in place…
The list could go way beyond Flash, depending on how the rule is interpreted.
Google behaves in predictably evil ways.
Apple remains innovative in their evil behavior.
It’s surprising to me how many dozens of articles have focused on a tiny little extension of Apple’s incredible power over App Store developers. The written rules have changed a bit: so what? Apps still get rejected for all sorts of unwritten reasons or just sit unapproved for “continued study”.
So, if you will indulge my claim that backwards compatibility is hard (even absent the private API issue) it is pretty easy to see why supporting other runtimes is ceding a lot of control to a 3rd party. Imagine if 10% of the apps on iPhone came from Flash. If that was the case, then ensuring Flash didn’t break release to release would be a big deal, much bigger than any other compatibility issues.
Lots of applications using the same framework or library (that only uses public APIs) should, overall, reduce the amount of work that needs to be done to maintain compatibility. There are fewer roads to maintain, and each fix is magnified to hundreds or thousands of applications. Gerbarg is saying that Apple would prefer that each developer reinvent the wheel to prevent the wheel manufacturers from gaining any influence.
The reason is that I think Adobe holds much more of the blame. Adobe is a large company with a significant, and complicated, relationship with Apple. They have frequent high level contacts and meetings. Adobe has known for quite some time about Apple’s desire not to have Flash on the iPhone. There is no doubt in my mind that if they asked Apple to bless this they were rebuffed, and if they didn’t ask the only reason they didn’t was because they knew Apple would say no.
Of course Adobe should have asked for a blessing. They should have known that it doesn’t matter whether you follow Apple’s rules. What matters is whether Apple likes you or sees you as a threat.
Apple should also find some way to loosen the license to officially allow games to use included interpreters for their internal logic. I don’t know how to do that without opening up loopholes, but that is what lawyers are for. If they don’t do that then effectively they are just using their discretion on a case by case basis, which is completely legitimate, but causes significant uncertainty for developers. Ideally Apple should have some provisions for adjunct or secondary runtimes that let developers use internal scripting.
It strikes me that this whole issue is mostly about politics and appearances. I doubt that Apple cares whether applications use libraries or interpreters or parser-generators for their engines. And I doubt that most developers who are upset about Section 3.3.1 care much about Flash. If Apple had simply said that Flash was banned, in any form, they would have achieved their goal, and the rules would be clear. But Apple didn’t want to say that, so they came up with the messy ideas of no interpreters and originally written in Objective-C. This seems like an impossible line-drawing problem, so I think we can expect more convoluted, post-hoc rules and discretion going forward—and, thus, more risk for developers.
Joe Berkovitz, quoting Apple:
10.4 Press Releases and Other Publicity. You may not issue any press releases or make any other public statements regarding this Agreement, its terms and conditions, or the relationship of the parties without Apple’s express prior written approval, which may be withheld at Apple’s discretion.
So, once you start developing for iPhone OS 4.0 you can’t complain about or even mention Section 3.3.1.
Daniel Jalkut has a great debugging story:
This seems impossible to me. Creating a new document and typing into it is fundamental to my product. Surely if it was broken I would know from my own daily testing of the application. I try diligently to reproduce it, but of course, I can’t. Create a new document. Start typing. Everything works, everybody’s happy. Except the person who reported the bug.
I’ve recently had a false start with Apple’s iPad Case. I cannot believe Steve Jobs greenlit this thing. The tacky/sticky case surface is a magnet for dust, dirt, and (most unfortunately) cat hair. Putting the iPad in the case and taking it back out feels akin to performing surgery. The bottom of the case in landscape mode becomes the inside of the case in portrait mode, which gets stuff on the iPad screen. And, while the case is a huge pleasure to use at an angle in landscape mode, it is ungainly and uncomfortable to use in portrait mode. I would also love a case that works with Apple’s iPad Dock and am disappointed to see Apple’s own case doesn’t work with Apple’s own dock.
I have to agree that Apple’s iPad case is shockingly bad. Perhaps it’s trying to do too many things?
If there are multiple contiguous object stores,
NSFastEnumerationallows the collection to return interior pointers one after another, allowing for a quick loop implementation over each store, and requiring an Objective-C message only for getting the next interior pointer. For collections without contiguous storage,
NSFastEnumerationallows the collection to copy objects out to temporary storage in bulk, reaping many of the same benefits. For collections where none of this works,
NSFastEnumerationstill allows a collection to efficiently return objects one by one.…Nice syntax, good performance, it’s a great combination.
Unfortunately, you can’t use fast enumeration if you support Mac OS X 10.4. Currently, I write all my loops using a
foreach macro, which conditionally compiles to IMP-caching and
NSEnumerator under 32 bit and
for…in under 64-bit.
Yesterday, AT&T launched a new brand campaign that introduces the theme of “Rethink Possible” and tries to do what few other companies—like Nike, Target and Apple—can, drop the name from the logo.
What Apple doesn’t want—and as we see now, is not going to allow—is for anyone other than Apple to define the framework for native iPhone apps.
Cross-platform software toolkits have never—ever—produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy. On the other hand, perhaps iPhone users will be missing out on good apps that would have been released if not for this rule, but won’t now.
Leaving aside the question of whether it’s reasonable to ban cross-platform applications rather than let customers decide whether they’re useful, I worry that this new regulation will also affect native applications. There are a variety of reasons that a developer might want to leverage other languages (either at build time or runtime) for code reuse, libraries, or development speed and power. Consider, for example, an AI or game engine written in Lisp that compiles down to ARM assembly or C. Hank Williams writes:
Developers are not free to use any tools to help them. If there is some tool that converts some Pascal or, Ruby, or Java into Objective-C it is out of bounds, because then the code is not “originally” written in C. This is akin to telling people what kind of desk people sit at when they write software for the iPhone. Or perhaps what kind of music they listen to. Or what kind of clothes they should be wearing. This is *INSANE*.
What will the next rule change be?
Update (2010-04-10): Hank Williams explains this a bit more:
By defining the rule as being about what language something is “originally” written in, we now must be supposedly concerned about the provenance of our code, and not just what it does. If a math library, or a physics engine, or a string package, or whatever, was originally written in some other language, and ported, then it violates this rule. This concept of what language something is written in is an insidious concept and strikes at the core of product development and of computer science in general. Everything is built on other stuff, the language provenance of which is often unclear. This language is fundamentally unreasonable, and un-enforceable.
I’m not convinced by his legal arguments (IANAL), but I think the important point is that Apple’s attack on cross-platform interface toolkits (of which I’m no fan) causes collateral damage and bans (should they choose to enforce 3.3.1) lots of libraries, tools, and techniques that could be used to develop top-notch, fully native iPhone OS software.
Overall, I’m excited and positive about this update. There was one thing about the presentation tough, that I felt was a negative. I thought some of the answers given during the Q&A period were just outright disingenuous. The most blatant case in point was when Steve was asked about distributing apps without the App Store, His response was to point out that Android has a “porn application store that your kids can get to,” and then state that Apple “didn’t want to go there.” Whisky. Tango. Foxtrot?
Jobs is often remarkably candid, but then there are cases like the above and, “Cingular doesn’t want to see their West Coast network go down…”
So, here we have a blob of common code that helps define the platform and I can’t get to it. This sounds like private API to me, even if it isn’t actually in the pile labelled “UIKit”. Instead of finishing this and making it available, the code is seemingly included directly in each of the iWork applications. The claim of iWork using 100% public API comes off a bit like a kid finishing cleaning their room by sweeping the last pile of junk under the bed.
Apple has made some puzzling decisions over the last few years that leave one wondering if they really care about typography as much as they did in the 1980s when the Mac launched the desktop publishing revolution. As recently as 2005, Steve Jobs made typography a central theme of his commencement address to Stanford grads, but his actions as the almighty head of Apple haven’t followed suit.
From Lucida italic to Marker Felt, to the strange choices in iBooks, the contrast with Microsoft’s recent font work is striking.
And in fact (and this is the aforereferenced “funny part”), I type faster on my iPhone than I do on the iPad. That’s especially true for when the iPad is in portrait mode, which puts the keyboard size in a no-man’s land — too small to eight-finger-type, too big to thumb-type. But it’s also true for when the iPad is in landscape mode.
I’ve found this as well. He also has interesting bits about Safari purging pages and file sharing:
The workflow for iWork is downright antediluvian. It’s not just pre-Cloud, it’s pre-network. It’s effectively the “Who’s got the latest revision of this file?” workflow of the days when we moved files from one machine to another via floppy disks.
iPad-to-Mac transfer is a labyrinth of restrictions and complications. If you expect to transfer the same document between an iPad and a Mac multiple times, I can guarantee you will be grumbling before too long.
Adrian Kingsley-Hughes reports that Pages and Keynote destructively alter documents that you edit on the iPad (via Angus Wong). It’s reasonable to expect that the iPad won’t be able to display or edit everything that the Mac can, but to break a document because you fixed a typo on the iPad?
Secondly, since the iPad doesn’t support custom fonts, I found that Pages was not a good previewer to show people a document I was working on. The layout was all wrong. Air Sharing HD worked much better; it was able to display the document’s built-in PDF preview.
That’s not the kind of development or software-market environment I want to see, as it would be a waste of a great platform and great potential. Ideally, Apple should only publish first-party App Store apps that would be approved if they were submitted by a third party, and they should therefore use no undocumented or prohibited APIs.
He’s 13 years old and he has created and is selling an iPad app in the same store where companies like EA, Google, and even Apple itself distribute iPad apps. His app is ready to go on the first day the product is available. Not a fake app. Not a junior app. A real honest-to-god iPad app. Imagine a 13-year-old in 1978 who could produce and sell his own Atari 2600 cartridges.
I still think the iPhone OS platform is needlessly closed, so he presents a bit of a false dichotomy, but there’s no denying that the development opportunities are incredible compared with when I was a kid.
When we tried to plug the iPad into existing iPod or iPhone accessories, we discovered that some Macs and AC adapters we tried were able to charge the iPad; others caused the iPad to declare it was “Not Charging” despite it being connected and syncable. It turns out that the iPad has some very specific charging requirements.
For the past generation, we have been living in a world of self-service computing, more commonly knows as personal computing. The person using/owning a personal/self service computer is responsible for managing that computer themselves. All the digital chores - installing and updating software, preventing malware infection, backing up storage etc. are the user’s responsibility. Most users hate that.
The April issue of ATPM is out:
- Bloggable: Melts in Your Hand
- MacMuser: CoPilot Live’s Wheels Within Wheels
- MacMuser: Losers and Winners
- Apple Talk: Flat Line
- Next Actions: Inbox Overload
- Desktop Pictures: Sunsets
- Out at Five
- Qaptain Qwerty
- Software Review: Avernum 6 v.1.0.2
- Accessory Review: Commuter
- Accessory Review: Defender
- FAQ: Frequently Asked Questions
Let’s say you want to open the App Store on your iPad, and you know that you’ve put this icon at the bottom right of your apps. Turning the iPad shuffles the positions of your icons. The App Store now suddenly jumps to the middle of the second row…The App Store can no longer be found where you expect to find it.