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

How to turn off shared calendar alerts in iOS 6 and above

iOS 6 has a new feature where if you are using a shared calendar and someone else makes any change – creates a new event, moves and event, changes length of event, etc – then you will get an alert on your iPhone or iPad. Personally, I find this very annoying as often the people I share calendars with add or edit tens of events at a time and my iPhone just keeps beeping away like crazy.

I eventually figured out how to turn this alert off. Just go to the Settings app, scroll down and select “Mail, Contacts, Calendars”, then scroll down again until you see the “Shared Calendar Alerts” setting and just flick it off. Now your phone won’t have a fit when other people add or edit calendars.

Shared calendar alerts off switch

SBGetScreenLockStatus (iPhone / iPad / iOS)

I figured out the parameters for the iOS SpringBoard SBGetScreenLockStatus method.  At first I was sure it would only be setting one bool to say if it was locked or not, but actually it turns out that it sets two.  The second just tells you whether or a passcode is enabled.  I’m calling it via the SpringBoardServices so it’s simply…

bool locked;
bool passcode;
void* (*SBGetScreenLockStatus)(mach_port_t* port, bool *lockStatus, bool *passcodeEnabled) = dlsym(sbserv, "SBGetScreenLockStatus");
SBGetScreenLockStatus(sbPort, &locked, &passcode);

Update: Stripping NSLog output for Xcode release builds

I previously posted a solution for stripping NSLog entries from Xcode release builds. However, that method no longer works in Xcode 4, since the variable it relied on (__OPTIMIZE__) is no longer defined by default. There is an alternative now though, since DEBUG is always defined. I’ve copied the bulk of my reasoning from the old post below, and put the new solution at the end, hope this helps…

I’ve had to move my webpage and looking at my incoming site stats it seems one of the most visited pages from my old site was the info on how to easily remove NSLog output from release builds for Xcode so here it is again for those that need it…

Objective-C developers frequently use NSLog to output strings to the console, particularly for debugging purposes. However, when you build a release version you don’t usually want any console output. This is especially true if you are building iPhone applications, where console output is more costly than on desktop OS X and can slow your app down. I’ve seen a few versions of tricks to help you remove NSLog output on release builds (for example, this one), but they all have two problems in common. Firstly, in most you have to edit your project settings and manually define a DEBUG constant. I find this rather annoying, as it just becomes a hassle to remember to go in and edit the project settings every time you start a new application. Secondly, they normally result in defining an alternative output method, such as DLog instead of NSLog, so you have to remember to start using the new version instead, and would have to go back and replace NSLogs in all your old code.

I came up with this small amendment that you put in your app’s prefix header, which I believe is a little neater than the other solutions I’ve seen…

#ifndef DEBUG
#define NSLog(...) {}
#endif

As DEBUG is normally defined for debug builds, you no longer have to go into your project settings and add any new definitions every time you create a new app. Furthermore, by overriding NSLog rather than providing an alternative definition, you can keep using NSLog normally instead of having to use an alternatively named alias. Therefore, I think this is the best solution, as all you have to do is copy and paste the above into your prefix header

How to spoof a MAC address on OS X Lion 10.7 (and probably Leopard)

It used to be a little easier to do before Leopard (10.5), but you can still spoof a MAC address rather easily in OS X Lion. If you don’t know why you’d want to spoof a MAC address then you probably don’t want to be doing it, but there are plenty valid reasons why you’d want to do so. Here are some steps on how to fake your address to the example MAC address of fa:ca:dd:fa:ca:dd, and there’s a more detailed description of each step below if you’re interested. Stuff marked like this should by typed into Terminal.

1. Decide which network interface you want to spoof, this is probably en0 or en1, remember which one you pick. I’ll assume you are using en1 for the remaining steps.
2. ifconfig Take a note of your current MAC address for your interface (en0 or en1) in case you want to revert later (but don’t worry if you forget, a reboot will always revert it to the real MAC address anyway).
3 (Wi-Fi only). sudo /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport -z
4 (Wi-Fi only). Wait about 10 seconds
5. sudo ifconfig en1 ether fa:ca:dd:fa:ca:dd

* Note if you want to know the MAC addresses of other devices already on the network you can view the arp table by doing…

arp -a

More detail on the steps for those who like to know what’s going on…

(1) Firstly, identify which network interface you want to change, the wired connection or the Wi-Fi. If you have both then they are most likely en0 for wired and en1 for Wi-Fi. If you only have one, such as the MacBook Air that only has Wi-Fi, then it’s probably en0. You can see a list of your network interfaces by typing ifconfig into Terminal. Alternatively, launch the Network Utility app in the Application/Utilities and you’ll see them in the drop-down list there.

(2) Regardless of whether you use ifconfig or Network Utility you’ll see the MAC address listed so take a note of it so that you can revert back later. By the way, if you forget it your machine will always revert to the true MAC address when you reboot anyway so don’t worry.

(3) The next step is to use the airport command to disassociate completely. This is necessary because if you try to set it to fake a MAC address and you are already connected to a network then the change probably won’t take affect. The command you use to do this is /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport. If you are going to be doing this a lot though then you may want to create a symbolic link to the command so you don’t have to keep typing the full path. To do that type in…

sudo ln -s /System/Library/PrivateFrameworks/Apple80211.framework/Resources/airport /usr/sbin/airport

After that you you can just type ‘airport’ from then on instead of typing the full path. So now to disassociate you just type…

sudo airport -z

(4) Even if your Wi-Fi icon goes grey immediately you should still wait 5-10 seconds to make sure it is fully disconnected before proceeding.

(5) This command is the one that tells OS X to pretend that the interface has a different MAC address.  At this point you probably want to check that the change has actually worked.  The easiest way to do this is to type the following and check that one of the results is the fake MAC you just set…

ifconfig | grep ether

How to handle ‘No previous prototype for function’ warnings in Xcode

When compiling code in Xcode 4 you may be seeing warnings saying ‘No previous prototype for function…’.  This is probably happening if you are using a library that has at least some parts written in C/C++.  This warning may even be appearing in code that previously compiled fine in Xcode 3 without any warnings.  This is because Xcode 4’s default compiler warns about this when Xcode 3’s did not.

Anyway, the warning is simply saying that a function implementation exists but no matching function declaration was found.  If you are used to Objective-C only this is like saying that you have the implemented code in the .m file but you don’t have the function listed in the .h.  It’s easy to fix, just write the method declaration in anywhere before the actual method; you can write it in the .m or .h, it won’t matter as long as it’s before the actual function.

For example, if you have a method such as…

float doSimpleMaths(float a, float b) {
   return (a*a)*(b*b);
}

Then to get rid of the warning just add in the method declaration before the method…

float doSimpleMaths(float a, float b);
float doSimpleMaths(float a, float b) {
   return (a*a)*(b*b);
}