Painted into a Touch Bar corner?

Back in April 2017 Apple invited a few select members of the tech press to a special event to discuss the situation with the Mac Pro line of computers. At that time the Mac Pro had gone about 4 years without any updates causing a lot of speculation about Apple’s commitment to its pro-level Mac users.

At the event Craig Federighi was quoted as saying:

“I think we designed ourselves into a bit of a thermal corner, if you will. We designed a system with the kind of GPUs that at the time we thought we needed, and that we thought we could well serve with a two GPU architecture. That that was the thermal limit we needed, or the thermal capacity we needed. But workloads didn’t materialize to fit that as broadly as we hoped.”

“The Mac Pro Lives”, DaringFireball.net, 4th April 2017
The 2013 Mac Pro

So whilst they didn’t provide an immediate fix to the problem it was a clear admission that the limits of the Mac Pro design had been reached and that there was no way they could upgrade that design to use newer, faster components. The only way forward was to scrap that design and redesign it completely.

Recently I had a purchase decision to make about a new Mac, I really wanted a good jump in performance over the 2014 13” MacBook Pro I’ve been using and ultimately I opted for a 6-core Mac Mini. 

After looking at all the options within the current MacBook Pro line I knew I wanted at least a quad-core CPU so it was going to have to be at least the high end 13” MacBook Pro, I also wanted 16Gb of RAM and at least a 512Gb SSD, so £2129 for this and an additional £249 to get AppleCare+ cover on top of this, plus the cost of a few dongles to connect non-USB-C devices to it and also my Thunderbolt display. All in all it was going to cost close to £2600 to get something to suit my needs.

In the end however I decided I couldn’t justify purchasing that machine. The reason I decided not to go for the MacBook Pro was that despite spending that amount of money I was buying a machine that had no future upgrade path. It’s not possible to upgrade the RAM or SSD storage so it means having to buy the highest configuration you can afford hoping that this is good enough for your future needs, rather than buying what you can afford now and adding upgrades later if needed. 

Additionally all of the higher-end MacBook Pro laptops come with the Touch Bar whether you want it or not so this adds to the cost, given that I work most of the time using an external display and keyboard it means the Touch Bar has limited usage potential. 

Having not owned a Touch Bar MacBook Pro I’m perhaps not in a position to judge how successful or beneficial the Touch Bar is, but my impression from articles etc online and friends who own one is that it’s not a must-have or key selling feature for many people. I know I would certainly rather have the ability to upgrade RAM and SSD storage down the line than have the Touch Bar.

Combine the Touch Bar with the lack of upgradability and you have to pay a lot of money up front to try and future proof your purchase. Ultimately I realised this wasn’t going to spark joy* and I would resent spending that amount of money to get something I wasn’t completely happy with and didn’t represent good value for money to me. In the end I opted for a 6-core Mac Mini purchased through Apple’s refurb store, the balance of price / features was much better and additionally the current models were released last year so they’re using the latest CPUs and aren’t likely to be superseded anytime soon.

So the question I’m asking is: Has the hardware choices in the MacBook Pro line resulted in a similar situation to the Mac Pro, only this time Apple has painted themselves into a Touch Bar corner? 

Personally, I think it’s time for Apple to consider what changes they need to make in the MacBook Pro line to get out of this corner they’ve painted themselves into.

* Yes, this is a token Mari Kondo reference :)

WatchOS 5 adds support for web content rendering

Apple recently announced updates to the core software on all of their hardware platforms with various interesting new features.

One feature that jumped out when looking through it all was support for displaying web content in watchOS 5, it’s important to clarify that they haven’t added a standalone Safari app to watchOS but instead it enables any links sent via Mail or Messages to be accessed and then displayed right on the watch.

To get a quick overview it is worth taking a few minutes to watch the “Designing Web Content for watchOS” video on the WWDC2018 videos site as it gives a good overview.

Here’s a few thoughts and info about key aspects that I picked up from watching the video:

User navigation / interaction

  • You can scroll using the Apple Watch’s digital crown or via pan gestures
  • Double-tap to zoom in / out on the page content
  • Back/Forward navigation is controlled either via an overlay UI brought up via a  firm press on the screen or by swiping back and forward from the edges of the screen.

Web browser feature support

Content is optimised for display on the Apple Watch so certain features are not supported in watchOS 5:

  • Video playback
  • Service workers
  • Web fonts

If the web content being accessed is responsive then it treats the content as being 320px wide, the same width as if on an iPhone SE (iPhone 5 or older width). So text may be smaller but at least it will basically render the smallest breakpoint content, so it doesn’t require any new even smaller breakpoint to be catered for.

This is done by overriding the “initial-scale” value and provides a viewport with the dimensions 320px by 357px and reports a media query size of 320px. So existing responsive content will render on the Apple Watch without requiring any changes – at least from a layout perspective, worth noting the lack of support for Web fonts as this will likely have some rendering impact as it falls back to alternative fonts in the font stack do display.

Optimising content for Apple Watch

Even though responsive content will be rendered quite well by default it is possible to optimise content for display on Apple Watch.

The above image shows the standard responsive content being displayed on the Apple Watch, basically just the same as it would be on an iPhone SE (minus any web fonts of course!).

Responsive Layout on Apple Watch

Using a media query it is possible to modify this layout to display as a single column. There is an example given in the video which obviously won’t apply for all uses, but basically it uses “min-width: 320px” as the baseline for showing the content as two columns, so any content below that would render as a single column. Again, how this works specifically for your layouts will vary, but there will be some methods to use for frameworks like Foundation or Bootstrap etc.

“Disabled-adaptations” meta tag

The important addition to using a media query though is a new meta tag which disables the default adaptations that the Apple Watch makes when rendering content by default:

<meta name=”disabled-adaptations” content=”watch”>

With this meta tag in place the device width will be treated as the real width of Apple Watch’s screen. This again has similarities to how content was handled when the iPhone originally came out, existing content is displayed as best as possible but there are ways to optimise for the device if you want to.

Form controls on watchOS

Making use of HTML5 form control types is really important on watchOS, setting the type attribute to “email”, “tel” etc will bring up a specific, full screen UI to allow interaction.

Additionally making use of labels, placeholder or aria-label attributes enhance the context given when interacting with these controls. Hopefully you’re using these already but here’s another reason to do so.

Safari Reader on watchOS

This is a feature found on iOS and macOS which basically formats pages to show a more readable version of web page content. It’s a little unclear from the video but it sounds like pages that are “text heavy” will get displayed using Reader, although I’m not 100% sure how that would be determined exactly if so. Perhaps this is a way to handle big pages that might have a lot of adverts on it? Reader view is an option that users can choose by firmly pressing on any page to bring up the navigation overlay, so even if content is displayed normally a more readable version can be accessed.

Semantic markup in Reader view on watchOS

Reader view makes good use of semantic markup, using the “article” tag helps the display of content, and attributes like “item-prop” and other semantic tags like “strong”, “em”, “blockquote” etc enhances the display of content in Reader on watchOS.

Open Graph meta tags

Using Open Graph meta tags is something that makes sharing content around the web such as into Facebook, Twitter etc look better by providing specific preview content such as images, titles etc. watchOS makes use of these Open Graph meta tags to make the previews for any shared links look as good as possible.


That’s a quick overview of some aspects of watchOS 5’s support for web content, there’s definitely a few things to consider in there but if you’re building pages using responsive layouts and using semantic HTML then things should work fairly well without having to do anything.

The biggest issue I see initially is the lack of support for web fonts, that seems like it could cause some display issues due to the fallback to alternative fonts in the stack or if web fonts have been used for icons etc.

I’m also interested to know what the impact on battery life on the watch is like when loading and rendering multi-megabyte web pages which are not uncommon these days, I think Reader view is going to be an essential feature for viewing web content on Apple Watch.

The Woman Who Gave the Macintosh a Smile

Interesting article on the New Yorker site, “The Woman Who Gave the Macintosh a Smile” about Susan Kare who was the designer of the original Mac computer icons back in the 1980s. I didn’t realise she was creative director at Pinterest now.

“But I loved the puzzle-like nature of working in sixteen-by-sixteen and thirty-two-by-thirty-twopixel icon grids, and the marriage of craft and metaphor.”

An illustrated history of iOS

Back in December 2014 I published a post about a great “llustrated history of Mac OSX” made by the makers of the Git client ‘Tower’ for Mac and Windows Since that time they have continued to update it to include more recent releases (and also the change the title to use “macOS” as Apple’s OS is known as now).

I noticed recently that the team at Tower have now followed up their OSX / macOS history with an “Illustrated history of iOS” which is a great concise history of Apple’s mobile operating system. It’s a nice little run through of the progress of iOS from 2007 until now.

Sidenote: I see Tower have just launched a public beta of an all-new version of their Git client, find out more on their blog: https://www.git-tower.com/blog/tower-public-beta-2018-starts/

How to fix “unable to boot device because it cannot be located on disk” in Xcode 9

I have recently been doing some development using the Xcode 9.2 Beta, but when it came to pushing the app to iTunes Connect I made the switch to the final release version of Xcode 9.2. In the process I ran various clean up tools to remove the beta version and related files etc.

However, after downloading and installing the release version of Xcode 9.2 and trying to test using the Simulator I encountered the error:

unable to boot device because it cannot be located on disk

This error also included a link to a location within simulator files which obviously is no longer there due to the clean up process I had used. I tried a few options but eventually found a series of commands that clean this up and fixed the problem for me. Make sure to quite Xcode and the Simulator app first and then run these commands in Terminal:

sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService
rm -rf ~/Library/Developer/CoreSimulator
rm -rf ~/Library/Developer/XCPGDevices

Hopefully after running them and starting Xcode the Simulator devices should all be functional again. Please note that if you have done any custom devices within your Simulator device list then these will have been deleted and the list reset to the default list of devices.

Remotely debugging mobile devices: Remote web inspection in Safari and iOS6

It doesn’t take a genius to note that mobile devices are pretty much overtaking the web, and that a huge amount of people – the majority depending on the statistics you pay attention to – are accessing the web via a mobile device such as an iPhone, iPad or other smartphone / tablet.

As such there has been a huge buzz about responsive design and how to make sites adapt well between a range of screen sizes and resolutions, and moving away from the concept of a fixed size of screen such as the ubiquitous 960 pixel grid framework. One of the biggest challenges in this new era of web design and development has been the lack of good tools to aid you in the process of creating responsive, adaptive websites.

Media Queries and Responsive Design

The ability to work in code and create media queries to handle various device widths and related styles has been possible for a while, but it can be a bit mind-melting trying to keep track of all of this and to test as you work through the development process. Fortunately we are now beginning to see a range of tools to help you develop responsive sites, one of the most recent being Adobe’s new Edge Reflow tool which is an app that lets you visually adjust the viewport and tweak the CSS of various media queries. It’s a simple, focused app that lets you resize the viewport and tweak the styles as you go. At the time of writing it hasn’t been released yet but when I get a chance I will definitely be checking it out and writing something about it.

Remotely Debugging Code on Mobile Devices

Another challenge with working with mobile devices is that you really need to test on actual mobile devices to get an understanding of the true behaviour of them. Although you can set the width of your desktop browser to be the same as that of an iPhone it won’t necessarily behave exactly the same way due to the differences in the way the browsers handle CSS or JavaScript.

One of the difficulties in testing on devices themselves is that it’s not very easy to debug when things don’t work as expected. On a desktop browser such as Safari you can use the Web Inspector to see the live code as you interact with it and also see any JavaScript errors that are triggered, but on a mobile browser there is often little available to help you detect the errors.

Thankfully there are now tools being developed to allow remote access to the code running on the device itself, Adobe developed a tool codenamed ‘Shadow’ (now formally released as Edge Inspect) which works by providing apps for various mobile devices such as iPhone, iPad, Android phones and tablets.

With these apps installed on your devices you then run a desktop app on your computer as well as an extension in Google Chrome. You can then view websites in Chrome and they will be simultaneously displayed on the mobile devices running the apps, but the key feature is that you can remotely inspect the HTML, CSS and JavaScript running in the app on those devices. A really excellent tool.

Remotely Debugging in Safari

Adobe Edge Inspect (formerly Shadow) is a great tool, but what if, like me, you prefer to work in desktop Safari as your main browser and don’t want to or can’t use Chrome to test sites? In case anyone thinks this is just down to a matter of personal preference of browser I can give a legitimate example of why having to use Chrome can be a problem – Chrome’s in-built support for Flash gets in the way of testing content that is intended as fallback or alternative content on the desktop.

Screenshot of Web Inspector settings in iOS6 on an iPhoneFortunately the recent release of iOS6 offers a new feature that enables remote web inspection of mobile Safari on iPhone or iPad.

To make use of it you need to go into the ‘Settings’ app on your iOS device, and drill down into ‘Safari->Advanced’ where you’ll find a new toggle button for ‘Web inspector’, (this replaces the old ‘Debug’ option in mobile Safari which really offered little functionality).

Switch this on and you’ll see a small paragraph of text appearing which explains that you need to connect your device to your computer with a cable for this feature to work.

Once you’ve enabled Web Inspector on your iOS device(s) then you should find them listed in the Develop menu in Safari on your computer, it should looks something like this:

You can select the device and then it opens up a menu showing the available applications that web inspector can open. Note that you need to have mobile Safari open on your iOS device for any sites to be listed in the menu, if they’re not open then you’ll get a message saying ‘No Inspectable Applications’.

Once you select a site from the menu then the familiar Web Inspector window in Safari on your computer will open, the difference is that you are seeing the HTML, CSS and JavaScript from your iOS device. You can then browse around and interact with the site on your iOS device and inspect all of the changes occurring right in Web Inspector. Here’s a view of the HTML from a site on my iPhone:

Debugging via the console remotely

Just as with the ‘regular’ web inspector you can interact, view and update HTML and CSS and then see these temporary tweaks appear right on your iOS device. The main benefit in debugging for me has been in dealing with JavaScript / jQuery code, I can make use of console.log messages and debug via the console just as I would when working on my computer:

In a recent jQuery mobile based site I was developing I encountered code that was failing in mobile Safari but working fine in Safari on my Mac – exactly the kind of situation I mentioned earlier in this article where code is handled differently in mobile Safari. But thanks to this new remote web inspector functionality I was able to easily add some console messages and figure out what was going on and adjust the code to work around the problem.

A Great Solution for iOS Web Development and Testing

iOS6’s remote web inspection functionality is definitely a huge improvement if you are making sites that you need to test on iOS devices. With the increase in Android-based devices such as Google’s Nexus 7 and Amazon’s Kindle Fire tablets you will of course need to test on other devices besides iPhones and iPads. So tools like Adobe’s Edge Inspect are definitely something you will need to make use of too for testing across the various platforms and devices, but the simplicity of this iOS-specific testing workflow is very easy to set up and work with. A definite two-thumbs up from me!

I’m going to take a look at some of the other tools available to aid in the contemporary web development workflow of responsive, mobile-friendly design and write some more posts about them soon. In particular an updated look at Adobe’s Edge Animate tool and also a look at the Edge Reflow tool once it has been released.

Tip: Fix for iPhone voicemail stopping working after upgrading to iOS6

Along with a gazillion other people around the Globe I upgraded my iPhone to the new iOS 6 software that just came out, everything worked fine during the upgrade but afterwards both myself and my work colleague found that our iPhone voicemail no longer worked.

In this case my iPhone is on the UK’s Orange network (soon to be known as EE) which along with every other carrier apart from O2 doesn’t give you the nice Visual Voicemail the way that Apple intended. Instead voicemail is accessed just like any other mobile phone since the 1990’s by pressing a voicemail button which then dials a number and you then access the voicemail by pressing numbers on the keypad.

However, I couldn’t even get that far, tapping the voicemail button just came up with an error messaging saying that voicemail was not configured and to get in touch with the phone company (or words to that effect). I looked up some support forums for Orange and on the Apple site but didn’t find anything recent relating to iOS6 but I did come up with something from a while ago which seems to have done the trick!

First you need to find out what the actual number is that you need to call to access voicemail, for Orange this is simply ‘123’. The next and final step is to enter the following sequence into the phone dialer on your iPhone but making sure to substitute the ‘123’ in my example for whatever the number is for your phone service’s voicemail:

**5005*86*123#

Just enter that and hit dial, the screen should flash quickly and after that your voicemail should now be working! If it doesn’t then you’re probably best either contacting your phone operator or visiting an Apple Store. But hopefully it will fix it!

Bonus News – Visual Voicemail coming to EE:

A bonus bit of news I discovered whilst I was googling for a solution is that apparently EE (according to their Twitter account) are going to add visual voicemail to their service in the new year, so Orange and T-Mobile customers should hopefully get that on their iPhones in future.

Why the next iPhone won’t be called ‘iPhone 5’…

I’ve been getting more and more bugged by people referring to the next iPhone as being the "iPhone 5", so I thought I’d make this simple graphic to explain why numerically it makes no sense for the next iPhone to be referred to as number 5!

You can download a 300dpi A4 sized version from this link if you want to print your own out and annoy inform any of your co-workers / friends / family / bloggers / podcasters when they start saying "what will the iPhone 5 be like?"…

My favourite new feature in OSX 10.7 Lion

This has got to be one of my favourite new ‘features’ in OSX Lion, it’s found inside the iCal app:

That unnecessary ‘s’ when displaying ‘1’ unit of time has bugged me for at least the last two versions of OSX, such a simple attention to detail but one strangely overlooked by Apple for such a long time! Now my OCD brain can stay calm when adding new events into iCal!