Apple is reducing the price of an out-of-warranty iPhone battery replacement by $50 — from $79 to $29 — for anyone with an iPhone 6 or later whose battery needs to be replaced, available worldwide through December 2018. Details will be provided soon on apple.com.
Early in 2018, we will issue an iOS software update with new features that give users more visibility into the health of their iPhone’s battery, so they can see for themselves if its condition is affecting performance.
The initial press comment felt rushed and incomplete, the public statement that has been posted on Apple.com is a pretty good response to the furore. Promising the discount only through to the end of 2018 is weak, though.
If Apple wants to consider iPhone batteries as consumable, I don’t want them to profit off of the battery repairs. $29 is a palatable service cost to bear after two years of iPhone ownership, $79 stings. If their aim is to maximise the longevity of their devices, they should not have conflicts in incentives with making money from repairs down the road. I do not want Apple to run a razor and blades business model, even inadvertently.
I’m interested to see exactly what battery statistics Apple will surface in the software update due ‘early in 2018’. When this update ships, I expect another wave of complaints from people as everyone will be able to see for themselves how degraded their own iPhone battery is. Regardless of the public reaction, transparency is critically important and what caused the fiasco to flare up so badly in the first place.
I would also like to see Apple release estimated numbers on how long customers should expect to be able to use their iPhone at full performance. This support document gives a rough idea about what effects the throttling will have on the user experience but I haven’t seen Apple say when customers should expect their iPhone experience to become less optimal.
The game launched fine off the 512mb card, but we were getting periodic, inconsistent system lock-ups when attempting to launch off of the 256mb card. We wracked our brains for a fix, but ultimately decided that our coding efforts would be best spent making the game as good as possible instead of chasing down some ghost in the machine.
So we shoved a 20mb music file into the game data, pushing the total file size beyond 260mb. This totally precluded us from having to involve the 256mb memory card in the submission process. It was a good game that we shipped on time. Microsoft and our customers were none the wiser.
This article is packed with examples of the unimaginable hurdles faced when shipping real software. Whilst the general motivations of these anecdotes are tightly coupled to a bygone era, when software had to be burned onto physical media with immutable finality, the underlying problems of unexpected roadblocks, edge-case gotchas, and deadlines are as prevalent as ever in the industry.
Games, apps, websites. It’s all just software that is becoming ever more complicated and sophisticated. The normal human tendency is to treat an app as a finished, complete, thing. Behind the scenes, there’s a lot of glue holding the walls together of a constantly-changing structure with developers doing incredible gymnastics of engineering to make it all ‘work’.
Ive, 50, was named Apple’s chief design officer in 2015 and subsequently handed off some day-to-day management responsibility while the iPhone maker was building its new Apple Park headquarters in Cupertino, California. “With the completion of Apple Park, Apple’s design leaders and teams are again reporting directly to Jony Ive, who remains focused purely on design,” Amy Bessette, a company spokeswoman, said Friday in a statement.
It’s hard to parse what this means because nobody on the outside really has a good idea of what the title change two years ago meant. Jony Ive’s elevation to Chief Design Officer felt like the first steps to his retirement with Howarth and Dye taking up the posts of lead hardware and software design.
Yet, Apple never tipped its hand that Ive was on the way out. I expected Howarth and Dye to slowly start appearing in keynote presentation videos, in interviews, and new product marketing. Ive would slowly fade from relevance in Apple’s public relations before he left for real. That simply didn’t happen. If anything, Ive became even more intertwined into Apple’s public image. He has done countless interviews and photo shoots in the intervening years.
Now, the managerial changes have essentially been reversed to what they were pre-2015. Howarth and Dye have been meekly removed from the Apple Leadership page and Apple told Bloomberg in a statement that they report directly to Ive once more. Was this the plan all along, or was Ive originally planning to retire after Apple Park was done? With no evidence to consider, I tend to lean towards the latter explanation as otherwise they wouldn’t have bothered announcing a role switch-up in the first place.
Once Apple decided to use beam forming, designers experimented with various shapes. One prototype looked like a flat panel with a mesh screen on the front. Another was about five times as tall as today’s 7-inch HomePod and packed in dozens of speakers. At one point Apple considered selling the device under the Beats brand but the idea was abandoned. There was discussion of adding a second woofer and including mid-range speakers to boost the sound quality even further. Designers also mulled producing the speaker in several colors but eventually decided on black and white. Over the years a closet filled up with prototypes, a kind of mini museum dedicated to the HomePod.
I always think back to the Apple-Samsung patent trials which included images of early iPhone prototypes as submitted evidence. There are some truly wacky designs in there. Nobody would believe that an angular phone would have been even been considered by the likes of Jony Ive and Steve Jobs without these court disclosures.
Apple surely experimented with a much larger smart speaker chassis, probably to identify the best balance of audio quality and physical elegance (size). I would be shocked if the HomePod line gets larger before it gets smaller. The average person will already struggle to differentiate the superior sound signature of the HomePod compared to rival products. Going larger would merely target a segment even more niche than the market it already appeals to.
Apple shared this statement with 9to5Mac confirming the delay:
“We can’t wait for people to experience HomePod, Apple’s breakthrough wireless speaker for the home, but we need a little more time before it’s ready for our customers. We’ll start shipping in the US, UK, and Australia in early 2018.”
When Apple announced the iMac Pro at WWDC in June, it made sense to do so despite the product not shipping until year’s end. Apple satiated the Mac Pro user base with a pledge to update it and the unveiling of the iMac Pro, which appeals to much of the same crowd. Even if you don’t want to buy one, it’s an impressive offering that proves Apple is still catering to professionals and should give some confidence that Apple will deliver on the modular Mac Pro promises with a product of equal calibre.
When Apple announced the HomePod at WWDC in June, I couldn’t understand why they chose to show it so far in advance. HomePod doesn’t have an SDK that developers could learn about, nor did it serve as a platform for a new wave of Siri features. Moreover, Apple didn’t need to scrape the barrel to find stuff to talk about. The WWDC keynote was jam-packed with hardware and software announcements. HomePod could have been cut and it would have still been a very impressive event.
I care less about the reason for the delay (it’s probably something boring) and more about why Apple felt pressured to announce their smart speaker prematurely in the first place. I’d love to hear the internal justification. In my view, HomePod could have been unveiled at the September event with no downside.
In a post for 9to5Mac, I brought up an area where the iPhone X currently does the wrong thing, at least in my opinion regarding the aesthetics of the home indicator. In an app with mostly dark content, like iTunes Store or the Watch app, the home indicator is coloured stark white.
This is not very nice to look at, the subtle greys and blacks of the application clash with the bright white rounded rectangle. It distracts the eye. You can see that in the screenshot above, on the left. If you are reading this post on an LCD screen, consider that the problem is amplified further on an actual iPhone X with its high-contrast OLED screen.
In the right-side mockup, I color-matched the home indicator with the text colour of the tab-bar items. This is a simple but very effective change. From a technical perspective, UIKit could easily grab that value from the appearance proxy — no additional API surface needed — for a much more pleasing result. The home indicator is unmistakably still there, it just integrates neatly with the app chrome.
Ideally, Apple would expose a dedicated API that lets each app decide what colour the home indicator should be in the current context. It already allows developers to set whether the home indicator should be temporarily hidden, to avoid disrupting full-screen experiences like watching video.
The automatic algorithm does a decent job at guessing the best colour for the indicator at any particular moment (it’s actually a luminosity-blended texture, not one single colour), but it would be better if each app could provide its own suggestion. The suggested colour would only be a preferred tint; the system could choose to override the developers’ wishes if it deemed it necessary.
Right now, the indicator is only ever depicted in shades of grey. That doesn’t need to change with the API extension proposed above; in fact it’s probably enough if the API simply let the app say what the maximum brightness of the indicator should be.
I think the Monday YouTube iPhone X videos were a shambles. Not because they were YouTubers, but because Apple didn’t give them sufficient access to create interesting and engaging videos.
Every Apple-sanctioned hands-on posted on Monday was the exact same, incredibly generic, rough overview of Animoji, Face ID and the bigger screen. Each video was shot in the same New York City location and felt incredibly scripted by the invisible hand of Apple PR, with restrictive guidelines on what they could talk about and limited time to handle (and shoot) the product.
With these constraints imposed, it’s no surprise that the videos are homogenous and drab retelling of certain features. I’m sure Apple PR loved it as a way to advertise their iPhone X talking points to a wide base of people for free, but as a collection it didn’t work.
What allows the tech press to create compelling content for Apple products is they have the freedom to take a review unit home with them, in their own unique environments and situations. Apple threw away the creative diversity of YouTube with how they orchestrated the Monday early access previews. I think it’s cool they are reaching out to more YouTube personalities, specifically small to medium size channels, but on this occasion it fell flat. Apple stacked the deck against them, they didn’t have the freedom to make captivating, immersive, videos.
You know who made the best YouTube hands on? Brooke Peterson. Her video had a story, it had a flow, it had a cool setting. The grittiness made it feel like real life, which is ironic given its illegitimacy. With the Apple-sanctioned videos, it was impossible to escape the artificial studio lighting of the demo room.
With the intelligence of Siri, users control HomePod through natural voice interaction and can conveniently access iOS apps that support SiriKit Messaging, Lists, and Notes. Siri recognizes SiriKit requests made on HomePod and sends those requests to the user’s iOS device for processing. To prepare your app, make sure that your SiriKit integration is up to date and that you’ve adopted all of the appropriate intents.
Here’s the flow. The HomePod listens for a request from a user. If it recognises it as a request meant for a third party app, it sends the necessary data to a nearby iPhone/iPad with the app installed. The iOS device sends the response back to the HomePod, which speaks the reply. It’s similar to how WatchKit 1.0 worked where the connected phone did all of the heavy-lifting for third-party Watch apps.
Requiring an at-home iOS device to handle a third-party app request isn’t much of a limitation, at all. I can’t think of a situation when I would be using the HomePod and not have the iPhone somewhere in the house. There are benefits to a satellite ‘remote control’ approach too: developers don’t have to do anything special to support HomePod, all service configuration will naturally mirror the user’s phone apps, and there’s no need for users to manage another list of installed apps.
HomePod is lacking in capability in key areas, though. The scope of SiriKit is small on iOS and it’s even smaller for the HomePod integration; limited to third-party notes, lists and messaging apps. Some of the SiriKit domains don’t make sense because they require mobility (workouts) or a display (visual codes) but there are others that could be useful if the technical infrastructure could support them. Hailing an Uber from your living room smart speaker is a first-world convenience that HomePod cannot serve.
It would also be nice if Apple opened up new SiriKit domains to coincide with the HomePod launch, to give it more functionality. Third-party podcast and music apps are notable omissions — relevant to HomePod, iPhone and iPad — but there is no news on this front whatsoever.
Most significantly for HomePod is how it behaves as a device shared by multiple people. Or more accurately, how it seemingly ignores any such attempt to be a shared home product at the software level. It seems like one user will sign into the HomePod with Apple ID and iCloud, and all Siri features will be funnelled through that one account. This applies to first-party and third party services.
If you look at the HomePod solely as an Apple Music jukebox, even that has data that is unique to different members in the family: personal playlists and mixes. The first version of the HomePod software appears to have no support for multi-user accounts at all. Not good.
So when Cupertino decided to go with OLED, it must have known that supply would be tight and the company would be relying on nemesis Samsung. Perhaps Cook and Williams were OK with this and figured Samsung would ramp up fast enough to ensure OLEDs for all, or maybe they thought alternative suppliers would come on stream.
The biggest bottlenecks in the iPhone X supply chain are not directly related to the OLED screen at all. The OLED panel is expensive (five times more costly to Apple than an iPhone 8 Plus LCD) and only available from a single supplier, but that screen can be produced at the required ‘Apple scale’ by Samsung.
It is true that adopting an (almost) edge-to-edge OLED screen had implications on product specifications; namely the need for Face ID as a replacement to Touch ID. The depth-sensing camera system is one of the parts that caused holdups in ramping iPhone X units.
Regardless, Apple handled the situation the best it could. They needed to bring out a revolutionary high-end phone this year; the 6-series chassis with forehead and chin was showing its age. I’m sure they knew about the potential pitfalls in the supply chain that could arise, natural for any product like iPhone X that uses new internal components at incredible volumes, but they simply had to take that on the chin or risk falling behind in the marketplace.
Instead of the X, imagine that Apple released a much more conservative phone as their 2017 flagship iPhone. It may well have been readily stocked in stores, but who cares if nobody is excited to queue up (figuratively) and buy it. It would also have been incredibly punishing to Apple’s brand reputation; the press would publish negative stories about Apple’s lack of vision and innovation in droves.
It’s just an untenable proposition. They needed an impressive high-end device, at any cost, and the iPhone X is exactly that. Millions of people are about to buy it on Friday. Millions more will be gasping to buy it as soon as they can. The production issues and lack of supply is frustrating … however it’s only a short-term concern. KGI’s Ming-Chi Kuo believes iPhone X production will ramp up to full capacity sometime in November.
Facing the choice between launching a radical new design with a few months of supply shortages, or heralding a ‘boring’ iPhone for another year, Apple clearly made the right decision.
Google attempts to do the same thing with a single lens that other cameras do with two: detect depth data and blur the background. Most phones do this by combining computer recognition with a little bit of depth data — and Google is no different in that regard.
What is different is that Google is much better at computer recognition, and it’s gathering depth data from the dual-pixel system, where the half-pixels are literally less than a micron apart on a single image sensor. Google’s proficiency at machine learning means portrait images from the Pixel 2 do a better job of cropping around hair than either the iPhone 8 or the Note 8.
The Pixel 2 cameras are very impressive. The sample photos are very sharp and the automatic HDR+ effects make most of the images look hyper-real, probably not the most accurate depiction of the real-life scene but they look good.
It’s also fascinating to see others do Portrait mode features with a single lens. As everything in technology follows a path towards miniaturisation, the Apple approach — a dual camera system — will eventually be obsolete. One day. As it stands, the duo component enables another camera feature that no single lens phone offers: optical zoom.
The 2x zoom of the telephoto camera is a huge feature. In fact, when the iPhone 7 Plus first launched, the only function the dual cameras served was higher-quality zooming. The depth effect Portrait camera didn’t ship until a month after the phone was released.
The ability to zoom without digital cropping is a big deal. It justifies having two ugly holes poking about the back of the phone, rather than one. It doesn’t matter that Apple can ‘only’ achieve Portrait mode by using two lenses until Google (or another prominent phone manufacturer) can do optical zoom with a single lens.
The Watch is cool, making apps for it not so much. WatchKit doesn’t give the developer much freedom when it comes to design. The interface is composed of pre-compiled layouts and generic UI elements, with limited customisation. It’s a rich templating engine.
Behaviours and interactions are only achievable for third-party developers on watchOS if someone at Apple has already invented them and exposed a checkbox in Interface Builder. Any dynamic transition or animation in a WatchKit app is basically impossible.
For example, you can transition a table row to a new appearance if that row changes height because WatchKit happens to support that. But if you want to cross-fade the contents of a row that has the same height before and after, you are out of luck.
Want to create a social feed with post summaries and photos that use a parallax effect to subtly shift perspective as you move through a story? No joy. WatchKit does not provide realtime scroll events to apps so there is no way to react to a change in view offset. Even if it did, the lack of freeform layout effectively makes it unfeasible.
Let’s pretend Flickr wants to make a watch app that showcases the best images of the week uploaded to the platform, with a wall of thumbnails that fills the watch display. Users could use the Digital Crown to zoom in and focus on a single photo in fullscreen. You could perhaps favourite it to find it again later on a Mac or iPad. Seems like an interesting app? Literally only in your dreams with WatchKit. (In my dreams, Flickr is also a thriving photo sharing site.)
You have to fight the system at every turn to do anything non-standard … and in most cases it still isn’t achievable. There are a few ‘advanced’ interactions that Apple has made special affordances for developers to take advantage of, but I can probably count the number of them on one hand. There’s a reason why all third-party watch apps look uninspiring and generic; there’s just not much you can do to make your own app stand out.
What really puts salt in the wound is that Apple has access to a completely different Apple Watch technology stack and doesn’t hesitate to take advantage of it in its own apps. In thinking what I wanted to say for this article, I started flicking through the honeycomb and trying to find a stock app that could be visually replicated by a third party. I really, really, struggled.
The examples I wrote up above were not invented arbitrarily. The parallax story feed is literally describing the Apple News app. The photo wall describes the interactions of the Photos app. The update-in-place custom transitions are used all over the system — I was specifically thinking of the Heart Rate app which dynamically updates the current heart rate readout using a rotary-dial text animation.
The kind of things Apple doesn’t let you do are critical things that makeup a rich and responsive application. These things should not be passed off as little niceties, they serve a significant role in making an app feel alive and more enjoyable to use. Let’s drive this home with more examples of stock apps doing things third-party developers can’t.
Messages uses a zooming effect for bubbles as you scroll through the transcript, and swipe actions for the summary cells on the main screen. Calendar pushes the title bar alongside the list of events. Music has a beautiful transition for scrolling between albums on the home screen, it feels like you are flicking between jewel case CDs on a shelf. Activity relies on a rich graphical representation of progress, the rings, with independent animations for each segment and several custom live-updating animated charts hosted inside table cells that scale up as the user scrolls.
Even something mundane like the contact list in the Phone app shows hundreds of rows with a large address book, far more cells than WatchKit can manage, and presents a custom letter-by-letter scrubbing interface when you scroll the Digital Crown quickly. Tap on a contact photo and it smoothly expands to fill the Watch display. These interactions are so basic I had to double-check I wasn’t crazy, but sadly it is true these things are all unavailable to external developers.
After looking at every app on my watch, I think three Apple apps could be implemented by an outsider: Alarms, Settings and Stocks. That’s it. (Alarms and Settings are very plain apps mostly consisting of standard table rows. Stocks has a dynamic behaviour where you can scroll/swipe through the detail views like vertical pages. This interaction is one of the few things Apple has packaged up for WatchKit developers to access.)
Apple engineers are using a completely different technology stack to create the system apps. They get to write real iOS apps with a watchOS appearance theme, essentially. Third-party developers have to use WatchKit — a completely separate abstracted framework that exposes only high-level interface objects (whilst creating UIKit components under the covers).
The current WatchKit API leaves no room for invention. iOS innovations like pull-to-refresh came about because the iPhone OS UI frameworks were flexible enough to let developers and designers run wild with their own ideas, if they wanted to. Some of these custom controls worked so well Apple later incorporated them as standard components in UIKit. That free reign creativity simply can’t happen on the watch at the moment. Apple defines what is possible.
I hope this adequately conveys the frustration I had developing Visual Codes for Apple Watch. There’s no freedom to make what you are imagining in your head which means, for me, there is almost no fun in making it either. I did it because I had to.
Unlike iOS, making a WatchKit app is like a chore where you have to do a set number of things in a set number of ways. And that’s just an exposition of the UI side. I haven’t even covered the restrictions on what features are actually implementable on current watchOS. Those functional limitations preclude many categories of Watch apps from being made at all.
In addition to launching a smaller, cheaper Assistant smart speaker this morning, Google also unveiled the Google Home Max. Larger than last year’s Home, it features stereo speakers and a more premium design.
On the audio front, there are dual 4.5-inch high-excursion woofers with “custom” .7-inch tweets. The speaker cover is made of an “acoustically transparent fabric,” while there is a rigid polycarbonate housing. Google notes that the Max is 20x louder than the Google Home. Users can connect speakers via Cast, Bluetooth, or aux jack.
I’d be shocked if they sell more than a few thousand of these. It is expensive. At $399, it’s positioned at a price even higher than the HomePod. It’s also really expensive relative to the rest of the Google Home line.
Google already sells far cheaper smart speakers; in fact, they just announced a $49 Mini. I reckon that most people interested in a Google smart speaker product will just buy what’s cheap, and be very happy. The Max is a premium option that very few people will shell out for.
Similarly, Apple would sell far fewer $349 HomePods if they also sold a $199 model that had worse sound quality proportional to its lower price.
Nevertheless, ignoring market viability, I think the Max is pretty cool. The form factor is neat. It has a magnetic rubber foot that can attach to the short side or the long side. In its default horizontal appearance, it looks like it is meant to be used as an oblong. Yet, you can pair it with a second unit, orient them vertically, and it looks like it meant is to be used that way round reminiscent of ‘normal’ stereo speakers.
As with all the smart speakers that emphasise their music capabilities, it’s impossible to know how it stacks up without hearing it in person. Both this and the HomePod ship sometime in December — it will make for an interesting comparison.
On iOS, if you connect a hardware keyboard, you can actually open Spotlight Search and navigate between search results without ever touching the screen. KeyboardNavigationKit provides the same behaviour as a framework for any developer to add similar interactions to table views in their own applications. Check out the source on Github.
Use the up and down arrow keys to adjust the focused row. Press Enter to select a focused cell. Check the video for visual examples.
I’m very happy to finally be able to contribute to open-source iOS development with my first open-source Swift framework. KeyboardNavigationKit is used within Visual Codes right now, so it’s tested in shipping applications. Ultimately third-party implementations of keyboard focus will not be necessary, as UIKit will provide system implementations (UIFocusEngine is almost there already, but it’s tvOS only) as the iPad becomes more of a macOS replacement.
Feedback is very much welcomed. I am aware that documentation and example code is very much lacking. It’s on the to-do list. Shipping this fulfils a goal of mine I’ve had since the end of 2016, so here it is. I hope it is useful to someone.
Visual Codes creates QR codes that anyone can scan using their iPhone camera app. Send links, add a contact or even connect to WiFi, just by scanning a code. Only the person who makes the QR code in the first place needs to download Visual Codes app; any iPhone or iPad running iOS 11 automatically scans the code through the native Camera.
That’s the pitch. Here’s the backstory. I have definitely mocked QR codes in the past so at face value, it’s a bit hypocritical to then go and make an app that centres around them as a concept.
However, what changed my view is iOS 11 integration of a QR code reader at the system level. Becoming a first-party feature helps a great deal and reducing the friction of using a QR code. No third-party apps to download and launch, users simply open the Camera (which is instantly accessible from the lock screen) and point it at the QR code.
The QR format space is messy; there isn’t really one official standard on how a message payload is encoded into a QR image. The design elegance of Visual Codes is that I picked Apple’s implementation in iOS 11 as the ‘standard’ to write against. I can promise to support what iOS does, and nothing else. I can test against the devices I own and comfortably address a large audience (any iOS 11 device).
If the generated codes work on other platforms, then that’s great. If they don’t, I’m not going against the app’s premise. Incidentally, most of the codes will work with Android which is a nice sweetener.
Visual Codes is a niche app with a couple of obvious use cases (like creating a QR code for your home WiFi network) and then a wide space of potential niche applications. Marketing such an abstract generic utility is hard. The app is freemium for precisely that reason: people can try it out without having to decide if it is worth paying for.
The app was a fun project to make. I pushed hard to make the 1.0 not require a web connection at all. It’s refreshing to work on apps that don’t need to worry about networking; there’s just a lot of boring stuff that I didn’t have to concern myself with. Instead, I used the extra development time to experiment and play around with features like SiriKit and rich keyboard list navigation.
I think that was a good decision. If I had forced myself into networking for the 1.0, I might not have ever shipped it. I probably would have got bored debugging a synchronisation issue and given up on it entirely. The flexibility to abandon something is a blessing and a curse when it comes to side projects.
Of course, the most-requested feature since the app launched yesterday is cross-device iCloud syncing of libraries. This is something I obviously want to add. At least now, I have the motivation of a (partially paying) user base to satisfy when I inevitably hit a wall in the CloudKit implementation.
In terms of the interface design, my limited resource budget stunted some of the things I wanted to achieve. I scrapped plans for a custom iPad layout (likely revolving around a grid view for the main screen rather than a stretched-out list) and limited myself to only small tweaks for the tablet size class. My compromise was to make the app look good on the iPhone and in the iPad floating multitasking window.
The transition from code library to detail view is hacked together but it looks great and smooths out the navigation experience. I’m really proud of the custom Print interface with dynamic previews, I think it looks great and exposes a lot of advanced functionality without getting lost in configuration panes.
A secondary motivation for releasing Visual Codes was to have a shipping app that uses my open-source frameworks, dogfooding as it were. Until this year, I had no open-source repositories to my name. Now, I have two meaningful contributions to the open-source iOS community in the wings. Although I am yet to formally announce them, they aren’t exactly hidden so if you are that interested you can check my Github profile. I want to properly ‘reveal’ one of them later this week.
In general, response and media coverage of Visual Codes was way higher than I ever expected it to be. I am really grateful to anyone that downloaded it, and especially thankful to those that have already bought the upgrade. I am aware of some teething problems in the 1.0 release (people use really weird names for their WiFi networks!) but I’ve already pushed a bug fix update through to App Review. Such is the life of an app developer. I love it.
I don’t think Apple’s marketing of the iPhone X as the ‘future’ is really appropriate. Android manufacturers have gone far down the bezel-less line for a year now. The iPhone X is more drastic, boasting the highest screen-to-body ratio of any phone, but it doesn’t feel like something that should be applauded as debuting the technology of tomorrow, today.
This kind of design is what I expect top-end phones to look like in the here and now. Despite the X and 8 sharing so many component upgrades (SoC, camera, True Tone), I feel like I will never be able to recommend an 8 to anyone. I am so done with bezels, foreheads and chins.
For people needing a new phone, I would seriously consider saving money and picking up a discounted iPhone 7 or 7 Plus if the X’s $999 starting price puts it out of reach. Maybe carriers offer good promotions for iPhone 8 series that could tip the balance; I just know I do not want to pay full price for a bezelled device. Alternatively, hold off on upgrading until you can afford the X tier phones (whether that’s three months or next year).
This sounds negative but it is really a commendation of how much better the iPhone X is as a product. The design is beautiful. This is what I’ve wanted for a year and a half. The concept of a screen that traces the edges of the chassis is as good as I imagined it to be.
The iPhone X doesn’t fully realise that idea, of course. It has the already-infamous notch area at the top of the screen. A future generation of this phone will not have a notch, making the vertical symmetry as perfect as the horizontal. That is years off, though.
Waiting to realise the vision in its entirety would have been a mistake. Putting all those components below the display is going to take at least another three years of development. It’s not feasible to sit on a radical new iPhone design for that long. The other option would have been to take an Android-esque approach: no bezels on left and right with a slimmer top forehead and bottom chin.
The notch brings its own downsides, particularly with landscape layouts, but going all the way to the edge, mirroring the rounded corners of the body, is impressive, fresh, cool and a competitive advantage. Apple are the first manufacturer to achieve this look and it makes them stand out. Going with a typical candy bar style would have drawn criticisms that they were copying Samsung and the design had no unique characteristics.
It’s a nuanced discussion that will no doubt span months of conversation but that’s my guess at the high-level business chatter. Luckily for me, the conclusions match up with my personal preferences of what looks good. I hope iPads, MacBooks and iMacs adopt these style of screens as soon as possible. I can’t wait to see the iPhone X in real life.
Whilst everyone on Twitter rattles on about the sensor housing placement, I take more offence with the home indicator. I don’t even have the phone yet and I already want it to never be there. Right now, iOS 11 always shows the home indicator apart from a few select cases where it can be temporarily hidden, like watching a full-screen chrome-less video. This is a sensible default, the mainstream population will benefit from having a permanent visual cue for system navigation.
But I’m technically minded, I won’t forget to swipe up from the bottom of the display to go back to the Home Screen. For me, that indicator is wholly redundant and offers basically no value in exchange for limiting usable screen space for actual content. I hope a future iOS update adds a toggle in Settings to permanently hide the indicator.
The ramifications of dropping Touch ID for Face ID are hard to reason about until I have an iPhone X to use. For now, I’ll take Apple’s marketing of its convenience at face value. I’m sure there will be times when I miss the ergonomics of fingerprint recognition and other times when I appreciate the benefits of facial recognition. I would not rule out a return of Touch ID at some point, when they can eventually integrate it seamlessly behind the screen.
Pricing for the iPhone X is pretty much inline with what I predicted months ago; the most expensive model doesn’t exceed $1200. Amusingly, the iPhone 8 and 8 Plus actually cost $50 more than the 7 and 7 Plus did. Apple blames rising NAND costs for the increase. Regardless, it’s worth noting that the 6s and 7 phones stay in the lineup. Apple is defending against the price hikes at the high end by keeping around older generations. If some portion of the user base are drawn to lower tiers, that’s okay. There will be an influx of people spending more money than ever on their next phone to balance it out.
“Apple tends not to price far from the high end competition,” the analysts wrote. “With the Galaxy Plus at $840 and the Note at [almost] $950, we think a $900 price tag for the base OLED model makes sense.”
Apple doesn’t price their products in a vacuum but it’s not magnetically attached to what Samsung is doing, either. I think what UBS is overlooking here is that the ‘7s’ iterative models will keep Apple competitive at the same price tiers they always have. The OLED phone doesn’t have to fight off all cheaper competition; if you want a ‘normal priced’ new phone you can consider getting a 7s or 7s Plus.
The OLED iPhone is clearly going to be positioned as a premium device that appeals to anyone interested in buying brand new iPhones. In my mind, this means it has to be more expensive than the most expensive iPhone that exists today. That’s the floor. The ceiling is the level of affordability that allows Apple to attract the millions upon millions of sales they want, for people that want to stretch their wallets.
That means Apple will start pricing above what the maxed-out 256 GB iPhone 7 Plus costs today, $969, but not too much more. With those conditions, $999 for a 64 GB iPhone 8/Edition/whatever seems right to me. The higher end storage tiers would add another $100 like always. Every current iPhone user pays at least a little bit more for the new best model but it isn’t wildly out of reach to anyone either.