Windows Phone 7

In late 2009 a rumor floated that Microsoft were going to start from scratch with their Windows Mobile OS. At the time, I thought about how cool it could be, but it didn't sound like something Microsoft would ever do.

Well they did it; in about 18 months they started from scratch and created something wholly original and non-derivative of the iPhone, and it's even cooler than I had ever imagined.

Windows Phone 7 is a fresh start, designed around all the principles that Apple has made essential to the modern smartphone market. High-spec hardware, thoughtful and powerful design, multitouch ingrained into the core of the OS, smooth visual performance and animation, a singular app store model and comprehensive developer support. The UI concept is surprisingly (for Microsoft) thoroughly thought out, with minimal chrome - making the content center-stage. The design language, Metro, used throughout the OS is very modern and beautiful, albeit certainly not for everyone.

Windows Phone 7 'just works' in a way I've never seen a Microsoft product do; add your Google and Facebook accounts to the device, and suddenly your contacts are enriched by data from both services, including pictures, status messages, addresses, contact details and more. No setup required, it's all built-in. Your Facebook timeline is displayed in the Contacts app, allowing you to check up on what your contacts are doing. The entire experience is very pleasant. Similarly, the Photos app will show your albums from Facebook and Windows Live too, as well as a Facebook timeline of photo postings from your contacts, of course allowing you to comment on them. Photos taken with the onboard camera will also automatically upload to your Facebook or Windows Live accounts if you so opt.

While the first-party, native apps on the OS are really great, third-party apps are a bit of a mixed bag. They are created using Silverlight, and themed to match the rest of the OS. As such, while they make a good attempt at it, you can still tell that they're not native apps. Controls work in different ways, keyboard input is slightly sluggish, and performance isn't consistent. Naturally, since this is the first ever version of Silverlight on a smartphone, there's a lot of performance that can be added and issues fixed with software updates in time. The most egregious problem however is multitasking, or the lack thereof. This wouldn't be so much of a problem if third-party apps launched instantly, and didn't quit if you locked the screen, but right now both problems are very obvious - apps can take three or more seconds to launch at their fastest. I have no doubt that Microsoft will enable multitasking along with copy & paste in the next year, but right now it's a frustrating experience. The worst part for me is when you lock the screen while running a third party app: when you unlock the phone, the app will start resuming - if you hit the home button before the app finishes, the app will continue launching in the background and the phone will switch back into the app after it's done (even though you explicitly told the OS to go back to the homescreen). Nonetheless, I have been consistently surprised with the quality of third-party apps on Windows Phone 7, all things considered. Furthermore, even the most badly written app still inherits the charming Metro style and fits in very well with the OS.

I have been using an LG Optimus 7 as my main phone for a few days now, and months ago I spent a few weeks with a prototype LG WP7 device as my primary phone. I would be remiss if I didn't say I adore it; the Optimus 7 is very sleek and feels like a premium device, and Windows Phone 7 itself makes me smile every time I use it, as the Zune HD did (it being the first touchscreen device with an earlier version of the Metro design). The seamless service integration really makes the OS pleasant to use, and, since the iPad is my primary Internet device, I am not missing the iPhone one bit.

Microsoft set out to create a new phone platform that was as good as the iPhone, yet offered a rich choice of devices and form factors so that users can choose the one they want. There are clearly rough edges, but nothing that cannot and will not be fixed in due time with software updates. Microsoft really have bet the house on the idea of a consumer smartphone; this isn't going to appeal to the kind of people who choose Android, but it will appeal to the vast amount of people who don't yet own a smartphone. It may even appeal to many iPhone users (as I said, I adore the OS, no less). For a company whom everyone had expected to fade into irrelevance in the smartphone business, Microsoft has pulled a remarkable 180°. I can't wait to see where this ideology leads them; maybe one day they'll rewrite Windows from scratch too ;-)

Retina Updates

Just to keep you informed, Speed and Lights Off are now fully Retina Display ready, joining the previously-updated SameGame.

Aside from that, they have much better support for iOS 4's multitasking, and Speed takes advantage of new features in iOS 4 to be more accurate than ever.

All are free updates, so go get them now!

MeeGo

Until a week ago, I knew virtually nothing about MeeGo. I had known it was an attempt by Nokia and Intel at creating a new OS for Nokia's smartphone line, and that was about it.

This week I attended MeeGoConf on a whim, as it was being hosted in Dublin so I wouldn't have to go out of my way to attend. As a direct result, I have been bitten by the MeeGo bug; there is so much potential here that I never would have expected given its heritage.

MeeGo is less about Nokia trying to be relevant, and more about the open source community creating the future Linux OS for embedded devices (smartphones, tablets, netbooks, in-vehicle entertainment and television). It's a full Linux distribution, a MeeGo 'Core'. For each device platform, there's a corresponding 'UX' (User eXperience); if you install the netbook version of MeeGo you're seeing the 'Netbook UX'. Evolved from Moblin, the Netbook UX is the most far-along and usable of the UXes.

Intel went out of their way at this conference to prove MeeGo to the attendees; what better way to convince someone something is worthwhile than to provide them with it for free and let them just use it themselves? Intel did just that, giving each of the ~700 third-party attendees a free Lenovo IdeaPad tablet netbook running MeeGo (to satisfy the nerdy body of attendees, everyone had to install the OS themselves from provided USB keys; the choice at collection was 'Broadcom' WiFi driver or 'open source' one :o) ).

MeeGo's Netbook UX is really well suited to touchscreen devices, and I was blown away by how smooth and responsive input was (stark contrast to Windows 7 on a touchscreen). I knew this was just the tip of the iceberg however, and I wanted to get the Handset (smartphone) UX up on running on my new tablet. A bit of massaging later (I lie, a *lot* of massaging - I now have the entire filesystem memorized) and I had my IdeaPad set up so I can switch between Netbook and Handset UX at a whim.

I went on a hacking spree after that, forcibly installing MeeGo on both my N900 and Nexus One. Right now, the Handset UX isn't usable for anything. It's just a pre-alpha glimpse of something with great potential. My N900 had previously convinced me that maybe Nokia wasn't going to wither into irrelevance after all (the OS, Maemo, that preceded MeeGo is very slick, and a stark contrast to Symbian S60), but now I'm downright excited to get my hands on a real MeeGo device, like the forthcoming N9.

MeeGo looks like it has legs, and is a distinct, user-friendly OS. But, influenced by the N900 that came before it, MeeGo is also a hacker's dream. A fully open-source OS that has a full Fedora-based Linux distribution under the hood and can potentially run desktop apps without issue (MeeGo's Netbook UX is a better Chrome OS than Chrome OS itself!). There's definitely another 6-8 months work before consumers can be entrusted with it, but from listening to the sessions all week it's clear that the people in charge are on the right track and know what they need to do to match the competition in the user experience space. I only hope that, like the N900, MeeGo handsets retain the Terminal app on the homescreen and the built-in SSH server. :-)

Return AirPrint sharing to Mac OS X v10.6.5

Today, Apple released Mac OS X v10.6.5 which was supposed to bring AirPrint to any printer connected to your Mac. Only problem is, a last minute issue (due to patent trolling?) has caused them to pull support for AirPrint in OS X.

Don't panic! You can return it, but you're going to have to pull some files from a prerelease version of 10.6.5.

The files you need are:

/usr/libexec/cups/filter/urftopdf

/usr/share/cups/mime/apple.convs

/usr/share/cups/mime/apple.types

If you migrate those from a 10.6.5 prerelease build (there seem to be many floating around torrent sites and file sharing sites - build 10H542 works; naturally I can't link you to the files themselves, sorry!) to your machine you're just one step away from having AirPrint working.

The final key thing is you have to remove and re-add your printer in the Print & Fax preferences pane. Once you do that (and share your printer in the Sharing preferences pane) it should show up on any iOS devices that support AirPrint.

Nerdy extra info: Basically, doing this should add the image/urf mimetype to your shared printer, and a new Bonjour field 'URF'. Once you have those, it should work. Theoretically, there's no reason someone can't write a server application that broadcasts said Bonjour info and prints for you, so you don't have to use files from a prerelease build. I would expect something like that to appear over the next few weeks.

Thanks to Patrick McCarron for helping me debug this method

Good luck!

Mac OS X 10.7 Brain Dump

On Wednesday, Apple revealed their plans for Mac OS X 'Lion', which will bring a lot of ideas and research from iOS to the desktop.

LaunchPad

A lot has been made of Apple's new 'Launchpad' feature; basically a re-imagining of the iOS home screen for the desktop. It makes a lot of sense, application discovery, installation and removal has always been problematic on Mac OS X. But it also signifies something far more interesting for the platform - the idea is to create an abstraction between your 'Applications' and the /Applications folder on your hard disk. Maybe in an OS release or two, you won't even have an Applications folder on disk anymore - all your application access and management will happen through Launchpad.

This signifies, at least to me, a move away from the files and folders model of interaction with computers. As with iOS, the location the applications are stored in becomes an implementation detail. In the very near future, we may not even need a Finder app to browse our hard disk; folders just become metadata, and everything lives in a global 'soup' (Apple Newton users will be familiar with this idea).

Never Quits

According to rumors I've heard, and evidenced in the demo of Lion given, apps in 10.7 also do not seem to differentiate between 'running' and 'onscreen'; there is no indicator in the Dock when they're open, and when you quit them and reopen them they re-launch in exactly the same state you left them. You effectively do not know what's running or not without a window onscreen. It sounds like an insane change, but actually isn't if you think about it: in the near future, there may not be a speed difference between something being 'in-RAM' or on-disk, if the two storage media are equivalent in speed (SSDs, while still a long way off, are getting there). If disk access is as fast as RAM access, what *is* the difference between 'quit' and 'offscreen'? There effectively is no difference. It may be a bit premature for 2011, and perhaps this decision will be reversed by the time Lion is released, but it's an interesting view of the future.

App Store

Apple also announced plans for an App Store on Mac OS X, something I've seen coming as a logical conclusion ever since it came to the iPhone. Feelings are mixed about this, but it doesn't matter - in the next few months the App Store is going to become the dominant distributor of Mac applications and developers will be scrambling to retrofit their software to abide by the store's rules. Whether the walled garden is good or evil, there's no doubt that it will change the desktop computing landscape just as it did in mobile.

Right now, you can't use the same application ID for your iOS app and your Mac App Store app. I think it's conceivable that in the future there will be no difference between a Mac and iOS app binary, so I can understand why they don't allow you reuse the same ID across both platforms.

Speaking of App Stores, I find it curious that neither Dashboard Widgets nor Safari Extensions have received an App Store of their own yet; I can definitely see both getting their own integrated stores eventually, as it just makes too much logical sense. I'm totally against putting either in the Mac App Store, however; that would defeat the purpose of a single-purpose, streamlined store.

Still no mention of iBooks on the desktop either - I've always imagined that Preview would gain such capabilities, but it's also possible that a standalone 'iBooks' app for Mac is coming.

Multitouch

Apple devoted quite a lot of stage time to talking about multitouch on the desktop, and saying how their solution is their powerful multitouch trackpad. They reason that touch screens don't want to be vertical, and they're fully right. Unlike many in the media, however, I certainly do not interpret this as Apple saying they won't implement multitouch screens on the Mac line. On the contrary, they kept saying how *vertical* touch screens don't work. This leaves them wide open to introducing horizontal touchscreen Macs, and they have many patents on such ideas so have obviously been working on them. Don't be surprised if in a year or two Apple introduces real touch screens to the Mac.

Lion looks to have much better, integral multitouch gesture support, which is going to be awesome for pro users. Right now the mouse is generally a point and click affair, but with multitouch it turns into something far more like a practical version of the Minority Report UI; every flick, swipe, pinch, rotate has a function in the OS.

Contextual UI & Fullscreen

This is also a big one - of course, people have defended iOS' unitasking and fullscreen apps saying it allows them focus better on whatever they're working on on iOS. There's a lot of truth to that, and it will be interesting to see how much of a difference it will make on the desktop. I definitely feel more at-peace and relaxed when unitasking on the iPad (this blog post was written on the iPad, for reference).

The contextual UI is something that interests me a lot; quite apparent in the iLife demos, specifically iPhoto, is a lot of contextual UI. It appears when it's needed, just like on iOS. It doesn't clutter the screen when not needed, and it shows up near the object you're interacting with instead of in some global toolbar or sidebar. I believe this is going to be a big thing as Mac OS X assimilates more of the design philosophy of iOS. It's definitely going to be a big deal on smaller screens, like the 11.6" MacBook Air. Mac OS X is also losing the permanent scrollbar, replacing it with a contextual scrollbar (again, just like iOS).

Wrap Up

There's so much coming in Lion that they've shown already, way more than I expected. I was expecting Mac OS X and iOS to become far more similar, but not this soon! Even now, it's clear that Lion is going to change the Mac landscape vastly, and the App Store is going to have a huge effect on Microsoft's planning for Windows 8. The stringent rules on the App Store will be a pain in the ass for Mac developers, but it will end up accelerating the evolution of the Mac platform immensely (no private APIs, no external dependencies beyond what ships with the Mac OS, no writing outside of specific locations - it will allow Apple to make huge and rapid changes to Mac OS X without worrying about backwards compatibility).

For the first time in many years, I am actually excited about the future of desktop computers. The iPad hasn't killed the Mac, it's brought it to a whole new level.

AppleTV + Apps

I guess it's no surprise that the new iOS-based AppleTV was jailbroken instantaneously on release, but as the former AppleTV plugin developers race to the new platform to disassemble it and get their own plugins up and running on the new system, I can't help but wonder how the future of AppleTV will play out as regards developers.

It's widely rumored that Apple will open up the AppleTV platform and create an 'App Store', allowing developers write apps for the big screen. It seems almost inevitable that they will make this play, if not to compete against Google TV then to at least make the AppleTV a relevant platform; leverage against the movie studios reluctant to agree to Apple's movie rental terms and who knows what else.

What I don't see is an AppleTV SDK being built around BackRow, the current framework that provides the UI on the device. Previous AppleTV plugins have all been built for BackRow, using a framework that is decidedly not very Cocoa-like or developer friendly. They have nonstandard design patterns, and they run as actual plugins to the UI process; a crashed plugin can currently take out the entire UI. From what I've seen (and I've been using it since the original AppleTV hacks back in 2007), the BackRow framework is not fit for third party developers and was never designed to be.

Assuming Apple does launch an App Store, then, how are we going to write apps? The only option I see is UIKit. UIKit is familiar to all iOS developers, is very Cocoa-like, and very powerful. In fact, since iOS 3.2, 1280x720 (720p, or the same resolution as AppleTV) is a supported resolution for developers, mainly for those creating TV-out UIs in iPad apps (Chopper 2 is a great example of this). Developers have already started crafting ten-foot-UI experiences in existing iOS apps, so it would be a no-brainer for that to translate over to AppleTV wholesale. To make it work, Apple would have to build remote control support into iOS… - but hold on a second, Apple already added that in iOS 4! Effectively, all the pieces are in place to build a remote-control driven 720p iOS app. All Apple needs to do is build the distribution mechanism and open the floodgates, and 'Universal' apps would be a definite possibility.

Of course, some people will complain that UIKit isn't the native UI for AppleTV; our apps will look and act differently from the native experience on the device. Point taken, and it's an important one; I think Apple could effectively build an AppleTV UI framework on top of UIKit that internally uses the BackRow APIs but offers the developer a much cleaner way to implement common features. Does it need to happen? No, but it would certainly feel unfinished if they didn't do it. Then again, Apple can be surprising: I'm still astounded they let the iPad ship with that horrific iPhone app scale-to-2x support :o).

Apple Financial Results Q3 2010

Little infographic for you; executive summary - the iPad in its first quarter of sales accounts for almost twice as much revenue as all desktop Mac sales.

Puts the future in perspective, don't you think?

Taken from Apple's financial results PDF.

Retina Display Update

By now, most developers have got their hands on iPhone 4 and run their old iPhone apps on it. And I'd like to think that they, like me, are appalled at how terrible they look on the new Retina Display. The screen is just so amazingly sharp and vibrant that your artwork will look like crap unless you get it redone.

Cue the sound of a hundred thousand developers' voices suddenly crying out in terror.

Why? Updating your artwork for the Retina Display is a time consuming and expensive process. iPhone artwork often costs thousands of dollars to produce in the first place, and if you have to go back to your artist to get it all redone (possibly from scratch, if they didn't think to design with vector shapes) then you're looking at a significant cost just to get your app to a passable visual state on the iPhone 4.

Those with in-house designers are at an advantage here, but for those of us who work alone it could well be a nightmare.

My plan is to have Retina-Display-ready app updates as soon as possible. I have already redone all the artwork for SameGame myself (and it looks stunning, to be honest), and Grace and Speed will follow with minor updates (in that order). Lights Off will require huge effort, so as of right now I'm not promising any release dates (just as with the Universal update, there's too much going into it to give a timeframe). Hopefully you'll start to see the others soon enough.

For those developers who haven't yet seen their app running on a Retina Display, start freaking out right about now. If you think you can get away with not redoing your art, you are sorely mistaken. :-)

PS: That Retina Display is like nothing I've ever seen. It changes the way you view computer screens forever. You can never unsee pixels on other displays again.

Labor of Love

I have downloaded (and paid for) a lot of $2.00 programs that are just amazing. It’s not that you couldn’t make these on the PC, it’s just that people would scream that it should be free. And as a developer, I can tell you, I won’t spend time making stuff "for free" when I could be spending that time with my kids unless it’s a labor of love. As a result, a lot of cool little programs are being made because developers can actually get paid for making cool stuff.

Brad Wardell, CEO/founder of Stardock (a long-time Windows development house), on the iPad as a threat to Windows.

Thoughts on Flash on Froyo / iPhone Safari Plug-In SDK

Some initial observations regarding my first twelve hours with the Flash 10.1 beta on the Nexus One:

Flash scrapes a pass in the performance test. Videos can be choppy at first, but after a little while they seem to play smoothly enough.

Flash utterly fails the UI test; forget any video playback controls on any Flash video you plan on watching. Tested it with the Engadget Show live last night and was unable to change the volume, also tested with some Zero Punctuation reviews and similar problem. It appears that Flash renders at the Nexus One's native resolution (480x800) which means the playback bar on virtually any Flash video is so tiny it's unusable. There's no automatic fullscreen mode when you double-tap a Flash context like some of the earlier demo videos mentioned, but the 'fullscreen' button on many Flash video players work fine (of course, Flash contexts that handle double-taps themselves to go fullscreen work fine).

Photograph here with SD card for comparison; you can't pinch-zoom in fullscreen mode, so how on earth are you ever expected to press any of the controls? This is worsened by the fact that Android phones' touch sensors aren't the most accurate either.

I can't give comments on battery life one way or another. The Nexus One's battery life is poor by default, but after watching a short Flash video or two I left the phone (in sleep mode) on my desk overnight; the battery was dead by the time I woke up.

Overall, for Flash to work on mobile devices virtually every Flash video site is going to have to redesign their Flash video player to support touchscreens. They may also have to re-encode all their videos for best performance (Flash keeps popping up 'This video is not optimized for mobile').

That being said, with the web as it is today, I don't see how Apple can ignore Flash for much longer unless there's significant movement to HTML5, which offers less features and generally performs worse than Flash, in the next year. To be honest, I don't see that happening; the pace of the web is glacial, at best, even when Apple is trying to force peoples' hands. It's really nice to be able to go to a website and not have to worry about whether it uses Flash or not; before this, I'd have to get a laptop out if a site demanded it. I don't think that's where Apple wants the iPhone or iPad to be, and I think the egos on both sides have done enough damage.

The Solution

I think Apple should put together a Safari Plug-in SDK for iPhone OS, and let developers decide. It's no more difficult to create a Safari plugin for iPhone than it is for the Mac, and Apple can sandbox them as much as they like, run them in a separate process and use IOSurface to draw them in a web view. Let the plug-ins access the same APIs that App Developers can, and let any developer submit them to the App Store. Why should Adobe get special privileges? Why can't Engadget, say, write an iPhone plugin that adds additional interactivity to their website when viewed on an iPhoneOS device? Should we wait for the web to catch up, or should we make something great using native code?

To prove a point, I have sample iPhone Safari plug-in source code available from my GitHub. You can test it in the Simulator, or you can test it on a jailbroken device. Make something amazing with it, and give Apple a reason to give us a plug-in SDK.

Update

I posted a video on Vimeo showing part of Lights Off running as an iPad Safari plug-in, just to give a concrete example:

'Open'

If you're going to have a curated experience, isn't it better to at least have one where the curator is making their decisions primarily around the quality of your experience?

Jeff LaMarche on Android and openness. I fully agree.

The worst part of all this talk on 'open' is that the Android source code Google provides isn't the complete source code, and doesn't include any of the Google portions like Maps, Gmail, etc. To get those, you have to pay a lot of money to get an Android license from Google.

There's no less lock-in with Android than there is with iPhone, the only difference is you can install any app you want without paying extra. You still have to root your Android device (/jailbreak) to do anything interesting. Pay Apple's yearly $99 license, and you also get the ability to install any app you want without using the App Store (among many other benefits). You're trading one walled garden for another, except Google doesn't have any design or UX sense.

Very interested to see how Google's all-out assault on Apple this week will affect Apple's plans for 2010 and beyond. Google doesn't seem content without trying to oust Apple from every market they have (except the Mac). This is war.

Karma, Baby

Although Google launched the Nexus One with grand plans to radically change the way consumers purchased phones and service, it looks like the experiment has fizzled to an end -- the company just announced that will eventually stop selling handsets online…

Google's flagship 'superphone' a complete flop, carriers rejecting it left right and centre, and now Google halting online sales. I love news days like these.

Via Engadget

Pixel Doubling

Public Service Announcement for Developers writing iPhone apps that are not Universal; if you use UIImageView to draw your UI elements, and create your art at double size (pixel size, not DPI), it will render at its native resolution on iPad.

This way you can provide an iPhone app that's not specifically compatible with iPad yet doesn't render horribly when pixel doubled on the iPad.

I'm guessing this trick will also position you well for any future iPhone with a higher resolution screen that may or may not be announced next month.

As you can see below, when run at 2x on the iPad, the artwork remains crisp (naturally at the cost of larger file sizes for images).

Update:

Just to clarify, using a 2x image will use 4x the RAM as a normal image; it's up to you to figure out how the performance affects your application. Also, I haven't yet looked into a way of drawing text at the higher resolution (rendering the text to an image and using that is a possibility, but I wouldn't recommend something that clunky).

The Future of HTML

From Wikipedia:

The first web browser, WorldWideWeb, was developed on the Nextstep platform. Some features and keyboard shortcuts now commonly found in web browsers can be traced to Nextstep conventions.

The basic layout options of HTML 1.0 and 2.0 are attributable to those features available in NeXT's Text class

Makes you wonder, if the NEXTSTEP APIs directly influenced the web (history lesson: NEXTSTEP was the OS that became Mac OS X), how much of the future of the web will directly be based on the technology and design patterns used in the iPhone OS?

You laugh, but a lot of HTML5 (canvas, css animation) already comes directly from the Mac OS X APIs, where they were implemented first.

Food for thought.

Related reading: Joe Hewitt's thoughts on the state of the web