WiFiFoFum Intrepid

I’ve been working on a new version of WiFiFoFum with Malc.  The codename we’ve used for the project is Intrepid, and it’s basically a complete rewrite of the WFFF codebase to get it compatible with iOS 7.

As many of you will know, WFFF for iOS has languished for some time due to Apple’s policies around Wi-Fi scanning.  Years ago WFFF was kicked out of the official App Store and we subsequently put it in Cydia.  Although it found an audience in Cydia, it got harder and harder to develop the app when Apple were not only denying us access to the iTunes Store distribution channel, but also seemed to be doing everything they could to block developers from accessing the Wi-Fi functions in iOS devices.

Dynamically Loaded felt it was time to try to push the boundaries again and, thanks to some simply stunning and ground-breaking work from Malc, he and I have created a version of WFFF that works wonderfully on standard iOS 7 devices… no jailbreak required!

I’m particularly proud of Intrepid.  A decade ago Malc and I were the first to figure out Wi-Fi scanning on Windows Mobile devices, and released WFFF as the world’s first widely available, mobile wireless scanner.  Half a decade ago we were the first to discover how to achieve Wi-Fi scanning on the iPhone, which led to the first iOS version of WFFF.  When Apple changed the Wi-Fi frameworks a couple of years later we again were the first to discover how to scan using new techniques.  Finally, when Apple completely removed Wi-Fi access via the iOS frameworks, even when using the hidden techniques we had discovered, I thought we’d never again be able to provide Wi-Fi scanning on jailed iOS devices.  However, with Intrepid we’ve done it, and I can’t wait to release it publicly and make the world’s best Wi-Fi scanner available to all iOS devices once more.

Our new scanning methods do not break ANY of the iTunes App Store rules so we will be submitting it to Apple and hope to have WiFiFoFum Intrepid available through the official store.  However, there are never any guarantees with Apple, so if for any reason they do not allow it into the store we will be making it available directly through the Dynamically Loaded site.

Intrepid will be ready for release soon, but in the meantime here are some screenshots of it running on my own jailed iPhone 5.

Network Utility in OS X 10.9 Mavericks

In OS X 10.9 Mavericks the very useful Network Utility app has been moved from its previous location in /Applications/Utilities to /System/Library/CoreServices. You can activate it by navigating to that folder and simply opening it as normal.

There is also another way to activate Network Utility. Simply open up the ‘System Information’ app, which can still be found in Applications/Utilities, then in the menus at the top of the screen open up the ‘Window’ menu and select ‘Network Utility’.

mavnetutil

How to: Create a bootable installation for OS X Mavericks 10.9 and above

UPDATE: With the release version of OS X Mavericks there is now a much easier way to create a bootable installer. Simply follow these steps.

1) Download Mavericks from the Mac App Store but do not click install. If you install then after it upgrades your machine the installer will be automatically deleted.

2) Insert a USB flash drive and use Disk Utility to format it, name it ‘Untitled’. The installer takes over 4GB so you’ll need at least an 8GB drive.

3) Open terminal and run the following command…

sudo /Applications/Install\ OS\ X\ Mavericks.app/Contents/Resources/createinstallmedia --volume /Volumes/Untitled --applicationpath /Applications/Install\ OS\ X\ Mavericks.app --nointeraction

4) You’ll see some output in Terminal letting you know it’s copying files. When that’s done your USB will be ready with the bootable installer.

iOS 7 thoughts

I am both excited and scared about the upcoming iOS 7 release.  Excited because it’s a chance for Apple to introduce many new and innovative features, and scared that if Apple don’t do this then we could see iOS sales really struggle for the next cycle.

iOS 6 was a relatively small update over iOS 5.  Whilst iOS 5 brought us some hefty new features like iCloud and Siri, iOS 6 brought much smaller improvements, and its main novel feature was the change from Google to Apple for Maps.app, which suffered some serious issues at launch.

If Apple follows its typical timeline for major iOS updates then it’s likely we’ll see the first developer previews of the next major update, iOS 7, in the next couple of months.  Given the increased competition Apple is seeing from the latest versions of Android, I believe iOS 7 has to be a significant upgrade with many new features. Apple have let iOS somewhat stagnate over the last few years, and they have to address that now.

When Steve Jobs first showed the iPhone he boldly stated it was 5 years ahead of the competition.  It’s been over 5 years since its release now, the competition has caught up, and Apple have to innovate with this update.  The new hardware this year will be incremental updates, with the iPhone 5S, a retina iPad mini, and minor form factor changes to the full-size iPad.  So, this is an ideal year for Apple to focus on their mobile software.  With a major change in iOS management, the departure of Scott Forstall, there must surely be momentum for not only a substantial software update, but room for a change in the ethos of iOS.

I expect to see a lot of major changes, and I have an extensive wishlist of improvements and new features that would take pages to write out, but what follows is a condensed list of what I think are reasonable guesses for what we could potentially see in iOS 7.

Integration

For a long time Apple has boasted of not just the ease-of-use of their devices, but of easy integration between devices.  In iOS, there is a great deal that could be improved in this area.  For example, many of us now own both an iPhone, an iPad and a Mac, or some combination of these.  However, when a call comes in on an iPhone, there is absolutely no notification of it on the iPad or Mac.  For me, this is often frustrating.  Sometimes whilst at home I leave the phone in one room whilst I’m on the iPad or Mac in another.  When my phone rings in the other room I don’t hear it, and even although I’m holding my iPad or have my laptop on my lap there is no notification to tell me who is calling.  By simply having the iPhone send a push notification to your other devices in this situation you would never unintentionally miss a call.

A slightly different, but annoying, behaviour occurs just now with FaceTime calls.  When I receive a FaceTime call all my devices ring, which is great.  However, if I answer the call on my iPhone then later on when I pick up my iPad it still has a notification that says one missed call.  However, the call wasn’t missed, I did answer it on my iPhone.

There’s so much more that could be done with improving device-to-device integration in iOS, but I think these are two good, basic examples of where some improvement could be easily implemented.

Remote

I am confident Apple is going to release a full television product, and when they do I think iOS devices should integrate with it to be a remote and a second screen.  I would expect iOS 7 to either have this functionality, or at least the seeds of it.  iOS devices should be able to perform as a remote and/or second screen for Apple TVs in a much more functional manner than they currently do.  For example, when viewing a movie on an Apple TV the iOS device should not just allow you to perform the standard remote controls such as play, pause, forward, rewind.  The device should also show additional useful information and functions.  For example, information about the movie, genre, actors, social functions where you can comment on the movie and participate in discussion.

Quick Access to Settings

I frequently use the Do Not Disturb feature that iOS 6 introduced to silent my phone.  However, accessing the setting that turns this on and off is slow and frustrating, primarily because I first have to find the Settings app.  Similarly, turning Wi-Fi on and off is slow.  Indeed, it is worse as it isn’t at the root level in the Settings app so you have to go into the Wi-Fi section to find the on/off toggle.  Commonly changed settings such as Do Not Disturb, Wi-Fi and Bluetooth power should be easily accessible from the Notification Centre pulldown.

Multitasking Improvements

I’m not sure about this one, as Apple has invested a lot of time and effort in creating a backgrounding system based on apps requesting the right to run in the background as they get location updates or play audio.  However, there are so many reasons for apps to run in the background that Apple have failed to anticipate and have been added in an ad hoc manner over the years that I think it’s time they just gave up and let apps run in the background if they like.  They could still require that users have to give permission for apps to do this, but instead of trying to section backgrounding into location, audio, VoIP the app could simply ask for background permission, which would allow apps to get the right to execute in the background for any reason, rather than just the ones Apple are able to think of right now.  A good example of a reason to run in the background that Apple hasn’t anticipated is to monitor the accelerometer.  I’ve tried to get an app to do this to track user activity levels for a fitness app, but since when it comes to movement Apple only anticipated the need for location backgrounding, an app that wants to track activity simply can’t run in the background (unless it also requests permission for another reason that is sanctioned by Apple, such as location).

Open Up the System

The jailbreak community is still thriving.  Just 24 hours after the release of the Evasi0n jailbreak there were over 1 million people who had used it.  Whilst I don’t normally have my own iOS devices jailbroken, there is a clear demand for it.  Although having iOS tightly locked down initially benefited Apple as they first began releasing iPhones, it’s time they opened up access to the device and OS more for developers.

Android is relatively open, and this allows developers to provide many novel and exciting apps that just aren’t possible in iOS.  Apple have already implemented a solution in OS X where users can decide to allow apps from the Mac App Store only, developer-signed apps, or any apps.  iOS should have the same settings in order to allow users to feel absolutely secure in using iOS Store Apps, whilst at the same time allowing them to experiment with the bleeding edge apps if they so desire.

Readster

I’ve just released a new RSS app called Readster.  I designed and created it with Malc.  We spent a long time thinking about how best to display news in a beautiful yet intuitive way, and I really think we achieved it.  As part of the app I also created a full-screen in app web browser mode, similar to Safari in iOS 6.  Pretty pleased with the way this app turned out.  If you are interested you can grab it by clicking here.

Why Apple will build a ‘cheap’ iPhone in 2013

There has been a great deal of discussion around whether Apple will release a cheaper iPhone or not. Many of those who say Apple won’t, seem to believe that to do so would mean Apple are cheapening the brand. Many of the rumors talk of such an iPhone being made of ‘cheaper materials’, such as plastic, and this implies a low-quality product.

I disagree, and I’m almost positive Apple will release a cheaper iPhone in 2013. The argument that Apple will not release a cheaper version starts to fall apart when you look at the company’s product history. Indeed, it’s hard to see a product other than the iPhone for which Apple has not offered less expensive options. Going back to the early iPod lineup, Apple released the iPod mini just three years after the original iPods. These were designed to be cheaper, and certainly had less storage than the fullsize iPods of the time. The original iPod when it came out in 2001 had 5GB of storage, and by 2004 when the iPod mini was released the standard iPod line was coming in 20 and 40GB versions. The first iPod minis had 4GB, less storage than the 3 year old original iPod. Many said nobody would buy it, yet the iPod mini quickly became a massive success, outselling the fullsize iPods.

Similarly, with the laptop lines, Apple has always offered at least a few options. We’ve had combinations of iBook, MacBook, MacBook Pro, and MacBook Air over the last decade, all with vastly different form factors, prices, and features.

A more recent hardware example is the iPad. Only this year Apple released the iPad mini, which looks to now be outselling the fullsize iPad. The fact that Apple are releasing cheaper versions of devices does not scare me at all. The iPod minis were a staggering success story, and it looks like the iPad mini is similarly off to an amazing start.

So, if you look at the hardware, the iPhone stands out because it is really the only Apple device that doesn’t come in multiple offerings. Remember, the iPod mini came out only three years after the fullsize iPod. It’s been six years now since the original iPhone came out… I think we’re overdue for a smaller, or cheaper version.

A second point is that, to Apple, cheaper does not mean low-quality. When the iPod mini came out it was in brushed metal rather than the plastic of the fullsize version. It felt like, and was, an extremely high-quality device. When the iPod nano came out it reverted to plastic again, and yet it too felt high-quality device, and started to outsell the iPod mini. Whether metal or plastic, Apple’s products never feel low-quality.

Finally, with Apple expanding into China the time is right for a lower-cost iPhone. The mobile phone market in China is very different than the US. Most customers save up and buy their mobile phones outright, and are not on contracts that subsidize the purchase price.

So, I certainly think a lower-cost iPhone is coming. Whether this is the iPhone mini or goes by a different name doesn’t really matter, but I do think it will be here in 2013. If it is, the most likely release date would be around the release of iOS 7, as this would allow for the major point update in the software to include many changes that may be required for such a device. This would place the release date sometime in summer 2013. iOS 7 betas are likely to start being seen around April or May, and when they are I’ll be examining the files in it to see if I can find any mention of new iPhone devices.

Examining iOS 6 Maps

I had a quick look at the way Apple’s new Maps app works in iOS 6 with my friend and colleague Malcolm Hall.  We’ve learned a few things by doing some simple tests.

We know Apple has use Yelp’s data to populate its maps with businesses.  Malc noticed that a restaurant near him in San Diego was mislabelled, the ‘Pacific Beach Fish Shop’ was labelled as an actual shop when it is, in fact, a restaurant.  He logged into Yelp and updated it with the correct label, marking it as a seafood restaurant rather than a shop.  Checking back a while later, we can see that on Yelp the business category is updated…

 

However, in Apple’s maps the business is still listed as a shop, with a yellow shop marker showing a basket, rather than the brown dining marker with the fork and knife (you can see an example of that marker at the top-right of the map)…

The fact that Apple’s map didn’t update whilst Yelp’s did tells us that Apple is using a static version of Yelp’s data.  That is, at some point Yelp essentially provided Apple with a dump of a snapshot of their database, and now unless Apple do something to update it themselves then the data will be getting outdated.

Next I checked the accuracy of Apple’s data positioning.  I noticed that nearly all items near me are mispositioned in Apple’s maps.  For example, in the image below you can quite clearly see that ‘Hardie for Peugeot’ should be quite a bit nearer the top of the map at the building surrounded by all the parked (Peugeot) cars.  Additionally, the brown dining marker is for Enrico’s chip shop, which is actually right on the corner of Main Street and Foundry Loan.  It should be exactly where I dropped the purple pin.  The yellow arrows show where the markers should be moved to.

Remember, Apple have got this data from Yelp, so we can easily to see if the mispositioned items are caused by Apple or Yelp by simply checking the data on Yelp.  Checking Enrico’s in Yelp gives this:

Yelp clearly have the location of Enrico’s spot on, positioning it right on the corner of Foundry Loan and Main Street where it should be. Thus, the problem is not with the data that Yelp hold and have supplied to Apple, the problem is with Apple’s copy of the data.  Most likely, Apple have either made an error when copying the data into their own system, or the database they are using has the wrong field type set.

So, this quick examination has shown two things.  Firstly, that Apple has a static copy of Yelp’s data; that is the Yelp data inside Maps app is not being updated live.  Secondly, that Apple have messed up some of the data they received from Yelp either during transmission/conversion, or through a mistake in storage.

Perhaps Apple will get periodic updates of data from Yelp.  For example, maybe they have a contract with Yelp that gives them updates every three months, and so at some point the Pacific Beach Fish Shop in Apple’s data will be updated with fresh information from Yelp and suddenly change to the brown dining marker in Maps.app.  Another possibility is that Apple now think they can do this work themselves, or at least get iPhone users to do it on their behalf.  However, given the strong Yelp branding in the Maps app I doubt this is the case, at least not in the short term, and they are more likely to be hoping they can rely on periodic updates from Yelp.

 

 

 

Apple design team: then and now

Here are two pictures of the Apple design team.  The first is from the early eighties and shows the team that created the first Macintosh; including Andy Hertzfield and Burrell Smith.  The second is from yesterday (18th Sept, 2012) and shows Jonathan Ive at the center surrounded by the other 15 members on the team.

Native versus HTML 5

As a developer who primarily writes natively for mobile platforms, I frequently get asked about native code versus HTML 5. Obviously, this happens most when people want to hit multiple platforms. They speak to developers who advise them that they’ll need to hit say at least iOS and Android, and then they’ll respond with something along the lines of “well, I’ve heard HTML5 runs on all devices, so I’ll just do that since it’ll be cheaper and then just work on everything”.

This issue has been reported in the mainstream media yesterday, as Mark Zuckerberg has publicly stated that using HTML5 on mobile devices was ‘the biggest strategic mistake we’ve ever made’, and that ‘it was really painful, we were never able to get the quality we wanted’. If Facebook had asked me 2 years ago when they started developing their mobile app, I couldn’t have more strongly advised against using HTML5. In some sense I can understand why Zuckerberg would make the choice he did though. He wrote Facebook initially using HTML, PHP and Javascript, that’s where he logged all of his coding hours. His experience of coding has all been web-based, and that is what he understands and is comfortable with.

As a developer who understands mobile platforms, it often grates on me when people view HTML5 as a viable solution in that space simply because they hear that it ‘works everywhere’ and flashing lights go off in their head as they suddenly see cost savings. There are a plethora of problems and issues that arise when mobile solutions are attempted with HTML5. Unfortunately, most non-techies, who are making the decisions, simply don’t understand the repercussions.

Note that when I talk about an ‘HTML5 app’ I mean an app that has a native shell that provides a standard web view, and then the majority of the app works inside that web view.

Firstly, HTML5 will always result in a slower and clunkier interface than native. For one, the app has to hit some server online that is hosting the HTML so there is the initial overhead of retrieving this. Whilst this may seem fast for one off operations, let’s say as an example one second, you have to remember that any serious use of your app is going to involve hundreds or thousands of these requests.  Waiting one second once is okay, waiting one second a thousand times is not. Note that in computing terms 1 second may as well be eternity, most native operations will be measured in pico or nano seconds. Once the HTML data has been received from the server, it still has to be decoded, interpreted and then the web browser has to conduct the appropriate work to update the display. All of these tasks are out of your control, you are relying on the browser to do this efficiently. Indeed, all of this assumes the user has a good Internet connection and the servers are working 100% of the time. If either of these aren’t true then an HTML5 app can fail in horrible ways, displaying blank or 404 pages.

Another issue is that an HTML5 app will never be able to make full use of the a mobile device’s capabilities; they are stuck with what HTML supports. Mobile devices are evolving from one month to the next, with better cameras, accelerometers, GPS, NFC… a never-ending multitude of sensors and capabilities, all of which are immediately supported natively.  However, HTML apps can’t access most of these, and if they can then they can only do so when support is eventually added and even then only in very specific and inflexible ways. For example, even though GPS hardware has been around for a long time and is in nearly every mobile device now, with HTML you might be able to get a location from the GPS, but you have to ask for it in a specific way. You can’t get rapid location updates, and you can pretty much forget about retrieving any other interesting information the GPS and location hardware can provide, such as altitude, speed, heading. Even forgetting the hardware and its sensors, HTML 5 apps can’t make full use of the excellent native APIs that most platforms provide. For example, on the iPhone there are APIs for sharing items via email, Twitter and Facebook. Users see these standard sharing items everywhere, and become familiar and efficient with them. These standard widgets are designed by the device manufacturers to be beautiful, and present information clearly in an easily understandable.  Yet HTML 5 apps are unable to use these, and will instead fall back to embedding features like sharing in the web view they operate within, the text will likely be small, and users will be forced to slowly figure out this new method whilst becoming increasingly frustrated as they strain to read the small text.

HTML5 apps also tend to really stick out, in a bad way, because they are unable to conform to the HIG (Human Interface Guidelines) of the device. Nearly all devices come with a set of guidelines about how developers should design and implement apps. These include things like how big buttons should be, how tables should be laid out, how information should be presented using standard widgets, etc.  Again, HTML5 apps can’t access these standard widgets that all other apps can.  They may try to duplicate them, but the duplication never quite looks right, and even if it is a good visual facsimile, when the user interacts with them they will be slow or jerky.  Basically, just as some human-looking robots fall into the uncanny valley and end up making people feel nauseous, these HTML attempts to copy end up doing the same for graphical widgets. Users look at them and expect one thing, and then become annoyed and frustrated when they behave oddly.

A final issue with HTML5 apps is that the primary claim of them working everywhere, across all devices, is just plain lies. Every device and operating system interprets HTML slightly differently.  You just have to try any HTML compliance tester (e.g. http://html5test.com) from multiple browsers to see for yourself how different the same HTML can be from one device or browser to another. The standard mobile browsers provided in Android, iOS and Windows Phone are all wildly different, and you can never be sure that the design you are supplying will always look or work the way you intended.  Add in screen size differences (tablet versus phone) and you end up with so many combinations that you can be certain that your HTML5 won’t be looking and working as you expected on at least some devices.

So, my list of HTML5 app problems are:

  • Always going to be slower than native
  • App may fail if servers go down, or connection is not available
  • Unable to use the full features of the device/OS
  • Unable to conform to the UX/UI guidelines of the platform
  • Actually not as compatible as you may think

In short, if you know for sure that you’ll never want to use any of the unique features and functionality that is currently available on mobile devices or that may come along in the future; don’t mind a slow, ugly, non-standard app; and truly believe that by some unknown magic HTML5 looks the same on all platforms and screen sizes; then sure, maybe HTML5 is a good solution for you.

Seriously though, don’t be fooled by the one claim that HTML5 relies on… that it just ‘works everywhere’.  It doesn’t.  Apps represent your company and your brand, they are a direct channel to customers. HTML is an ugly, slow and hacked together solution; don’t force that on your customers.

How to disable smooth-scrolling in Mountain Lion

Up until Mountain Lion, in OS X there was always an option to switch smooth scrolling on and off.  I think it was a checkbox called ‘Use Smooth Scrolling’ in the Appearance section of System Preferences.  An example of smooth scrolling is in Safari, where if you are viewing a web page and hit space then without it the page just immediately jumps to the next section, whereas if you have it on you see it very quickly scroll down to the next section. However, in Mountain Lion this option no longer exist and smooth scrolling seems stuck on.

If this annoys you then you can still turn if off by opening Terminal.app and entering:

defaults write -g NSScrollAnimationEnabled -bool NO