There were different tracks for developers to choose from, and one of the complaints we heard was that the devs wished it had been longer so they could have attended them all. Still, we have some notes they were willing to share, after the break!
(And if you think this is just for geeks… well it is, but it explains some of why the iPhone does what it does, and what developers could do to ease some of our frustrations).
WebKit
- One dev who was new to Apple technologies found WebKit and their specific CSS (-webkit-gradient, -webkit-mask, webkit-box-reflect) to be “astoundingly powerful”. (If you run WebKit or Safari-).
- Apple stressed the advantages of using WebKit and embedded WebView. The AppStore app is an example of a native app with a WebKit UI made by Apple.
- A button made in CSS is much lighter than an image file and also scales elegantly (resolution independent).
- Even a JPG that’s only 50k in size will take up 10 times more memory when it’s decompressed and rendered in a UI.
- WebKit interfaces can be updated outside of the App Store approval process, so no resubmission just to change UI elements.
- Client-side database storage API in HTML 5 saves state locally and reloads the next time you view the page.=
App Performance
- Apple believes every developer should be obsessed about performance.
- For the end user experience, every fraction of a second is important. They want to load and go, not invest time in waiting for an app to load.
- iPhone uses 12MB for graphics, 32MB for kernel, 12MB for daemons, 4MB for phone, so for iPhone 2G and 3G, half the memory is gone before any 3rd party app even loads.
- There’s no swap file, so the size of binaries matter since they’ll be loaded into memory.
- When a low-memory situation occurs, there’s a warning. On second warning, background apps are killed, on third warning (95%), front-facing app is killed. (Think Safari disappearing and getting dumped back onto the home screen).
- Apple stressed that developers need to handle these warnings elegantly and free up memory as/when appropriate.
- A user should never be warned about memory or asked what to do (hello AnDROID!).
- Where a developer stores cache is important. If a developer stores cache in a location that iTunes backs up, it creates slow iTunesbackups for users. They should cache in temporary areas instead.
- The iPhone uses a single core processor, but can handle multiple threads. In the future these devices may be multi-core so starting now and building them for that future is a good idea.
- Apple believes that great apps come from developers who pay attention to details beyond just what’s necessary to get the job done.
What About Those Rejections?
- The most common reason for a rejection, according to Apple, was when an app crashed on launch.
- Developers tended to know that if an API was private, they shouldn’t try to make an app that depended on it since it would likely get rejected.
- No specific rejections were brought up or addressed.
- One dev we spoke to liked the App Store and Apple as “gatekeeper” because it created greater end-user trust — people were more likely to trust that App Store apps would work and not mess up their phone or do anything criminal.
- Another dev, when asked about iPhone development vs. another platform, liked that Apple handled all the transactions and getting all the apps in front of all the users, which would be a huge chore and expense otherwise.
- Yet another dev just thought the size and reach of the App Store made it the best place to develop at the moment.
0 comments:
Post a Comment