There has been an increasing amount of talk lately about the idea of running Mac apps on iPads. This certainly isn't a new idea, with people wanting apps like Final Cut Pro and Xcode to run on iPads for almost as long as the iPad has existed, but it has really ramped up with the introduction of new iPad Pros featuring the same M1 chip as Apple's latest Macs.

Apple has finally released a version of their Developer app for the Mac, porting their iOS app to the Mac using Catalyst. The initial relief quickly gave way to frustration. As a basic app, it certainly functions ok. But it has so many little details wrong.

NSSplitView. One of the core components of any Mac app. It has changed a lot over the many years I've been building Mac apps. Early on, it was an archaic class that took a lot of time and effort to perfect. So much so, that some of the earliest "must have" bits of open source code for Mac apps were one of the many NSSplitView subclasses that made managing things like minimum and maximum sizes much easier.

Yesterday saw the release of the new Mac Pro, finally replacing the trash can and moving back to a tower-based design. It has had a somewhat mixed response, with many people taking issue with the high prices, ranging from $6000 to over $52000. There have been those seeking to defend the prices and write off the complaints, but I don't believe these arguments take into account the larger picture.

The computer industry can often move fast, with new technologies coming and going with dizzying speeds. Some lucky technologies are well thought out enough to stick around for decades, but ultimately all become outdated and replaced by newer technology.

I've had an idea for a new app for a while now, one that I've been eager to start working on. It's initially going to be a Mac app, but the concept could work fairly well on iPad too. Given the rumours around a new project called Marzipan allowing you to build for both devices with one toolkit, I opted to hold off until after WWDC before starting on the app.

Welcome to the second part of my Appreciating AppKit post. In the previous post I gave an overview of the many views and controls of AppKit that either don't exist or are not as powerful in UIKit. In this post I want to cover some of the more "behind the scenes" aspects of AppKit, things that help your productivity as a developer and can aid in the architecture of your apps.

WWDC 2019 is approaching and we are getting ever closer to finding out what form Apple's Marzipan project (which aims to enable developers to more easily port iOS apps to the Mac) will take when it is released to developers. Based on the scarce details we have, Marzipan seems to allow developers to build Mac apps using UIKit, with some additional features to make those apps feel like proper Mac apps.

Optimised code is something every programmer wants to write. We want our code to run as fast as possible using as few resources as possible. Unfortunately optimisation can often seem quite daunting. From needing to deal with parallelism, to knowing how to use profiling tools, to potentially even dropping down to assembly and hand crafting each instruction. Thankfully, most optimisation needn't be this complicated. Indeed, much like debugging, a lot of it can be solved with a few well placed log statements and a bit of thought about the problem you're trying to solve.

If you're at all familiar with Betteridge's law you'll know the answer to the title of this post already, but I want to discuss the reasoning why. Ever since Swift came out I've seen a lot of people who've jumped on the bandwagon proclaim that Objective-C is dead and anyone who isn't already investing in Swift is stuck in the past and will be left far behind. I've even seen some people proclaiming the past few days that developers who aren't using Swift now aren't worth hiring. Needless to say I think this is bullshit.

The mouse in the photo below has been my trusty companion for the best part of 9 years now. It, paired with the Microsoft Natural Ergonomic 4000, have been my main input devices throughout most of my programming career. It features 5 buttons, a rocker on the side (which could work as 3 more buttons) and a high speed scroll wheel, all of which can be re-configured to do a multitude of tasks using Logitech's driver software. It is the Logitech MX Revolution and it is by far the best mouse ever produced.

Motivation is a funny thing. It’s wonderful when you have it. It will lead you on and cause you to start projects. It keeps you going even when it may seem logical to stop. But it can just as easily abandon you, leaving you with a project (possibly several) that you feel compelled to continue simply because you’ve put so much effort in already.

Like most people, upon hearing of Swift, I rushed to download Xcode and the programming guide to try it out. 48 hours later I decided to leave it. I’ve tried it on and off since then and, while it has seen improvements, my overall opinion of Swift has stayed the same: it’s not yet fit for purpose.

When you spend all day working on a computer one of the most important things you can do is make sure you have good input devices, be that a mouse, a graphics tablet or, in this case, a keyboard. When you buy a Mac you usually get a Keyboard and Mouse (or Trackpad) included. Unfortunately, Apple haven't made a mouse even approaching decent since the ADB Mouse II. Their keyboards are pretty good, but for someone who is typing all day they have some flaws, the key one being that they aren't particularly ergonomic.

Autolayout is an incredibly powerful API that allows us to build complex and flexible UIs with minimal code. Any layout you can imagine can be defined in Autolayout. However, that is like saying that any program you can imagine can be defined in a Turing complete language. It says nothing to the simplicity or intuitiveness of the solution. So why are some layouts so awkward to produce in Autolayout?

Storyboards seem to be a big point of contention in iOS development. Some see them as wonderful additions, some as a poorly designed and pointless hindrance that Apple seems intent on force feeding us. There is one thing that’s consistent though: almost nobody is using them right.

There was a post by Florian Kugler going round recently about Autolayout Performance on iOS. It looked at how much time it takes Autolayout to add views, and how this increases with the number of views. The post, while providing very useful information, didn't seem to best represent real world performance of Autolayout, instead showing a set of worst-case scenarios.

Autolayout has had a lot of bad press. A lot of people find it complex, confusing and more hassle than it's worth. They find the APIs a bit awkward to work with and the tools provided seem to work against them and break what they've done. I'm wanting to change that, so I'm working on various projects to help people learn and use Autolayout.

Yesterday the first clusterfuck elections were held for Police & Crime Commissioners. These are meant to be elected officials that oversee policing and crime prevention in 41 areas (excluding London). The turnout for these elections has been laughably low, ranging from 10% to just below 19%. These are the lowest peacetime election turnouts in history. Evidently many chose not to vote, me included. But why was that? I can't vouch for everyone but I can at least give my reasons.

8:30am: Hello and welcome to this coverage of Apple's October 12th Maps press conference. Apple called this conference in response to the uproar over their new Maps applications.

Emacs or Vim? Tabs or Spaces? Mac or PC? There are many arguments between developers. One of the biggest ones in the Objective-C community is over dot-syntax. It's the argument that just keeps going. I'm on the side that doesn't particularly like dot syntax, but people often misunderstand the reasoning behind this position. So I'm going to outline it here.

A new year and a new version of Xcode 4. This of course means that it's time for me to drop everything and try to find out everything that's changed. Thankfully (for me at least), this is a relatively small update feature wise. I've been seeing two different responses to 4.3. Half of people seem to be experiencing a lot of crashes, but the other half seem to be seeing major performance improvements. I will be honest in admitting that I haven't really noticed either, but then again I'm still sure I have a special "more stable" build of Xcode that few others have. But besides that, what else has changed?

I'll start off by saying that I'm not suggesting you should not file bugs with Apple, you should. I'm also not going to suggest that Radar isn't a valuable tool to Apple, it is. But it's time to get something off my chest, something I've been wanting to rant about for ages.

I've spent a lot of time and words this year talking about what Xcode does have. At the same time I've spent quite a few tweets pining for certain features or wishing pain on those who are responsible for annoying bugs. I thought it would be an interesting idea to put together my personal wish list for the future of Xcode. These aren't in any particular order, though I have marked which are bugs I'd love to see fixed and which are features I'd like to see added. And finally I've included radar numbers where appropriate to allow you to file duplicates if you so desire.

The great Apple software release of 2011 happened a few weeks ago, bringing the likes of iOS 5 and iCloud. But we don't really care about those in this post, what we care about is Xcode 4.2. If Xcode 4.1 was the Lion release, Xcode 4.2 is the iOS 5 release (although many of the improvements apply to the Mac as well).

Lots of people have been writing posts describing what Steve Jobs's passing and life meant to them and how he influenced them. I've been struggling to figure out how to put my thoughts together and whether I really wanted to, as others have said most of what I wanted far more brilliantly than I could. However, someone who generally pisses me off, pissed me off to an even greater degree than usual. Said someone is Richard Stallman, or as I shall refer to him henceforth, Dick (as suggested by Justin Williams). The reason for this will soon become apparent.

Apple is no stranger to throwing out the old and changing things around. You can build something incredible, that makes lots of money and makes many people happy, but if you let that stagnate then people start to get restless. It's how the new kid on the block comes along and steals your thunder. So you have to change. People will get annoyed and even angry, as human beings are generally averse to big changes, at least to begin with.

Prior to Xcode 4 there existed the Build folder. I hated this folder, especially as I often wanted to zip up a project and send it to someone, and I'd end up having a huge file because I'd forgotten to delete the Build folder. So imagine my delight when Apple created the Derived Data directory in Xcode 4. This directory contains all the build products, intermediate files, indexes, logs etc. It is usually located in ~/Library/Developer/Xcode/DerivedData. The problem is, it is rather hard to find the particular Derived Data directory for a particular project…

Lion is a great OS. It has brought many great user features (Versions, autosave etc) and many fantastic developer features (Autolayout, popovers etc). It has brought one new feature though that is annoying a lot of users: Mission Control. I've mentioned some complaints I've got about it on twitter, but it's got to the point where I really need a blog post to convey my full opinion on it. I can't quite remember another change in an OS X update that was so big, yet so awful.

Another Xcode release, another review of what's new. Xcode 4.1 coincides with the release of Lion and includes many improvements, some to help adopt new technologies in Lion and some just to make Xcode a better IDE. So lets get started with what's new.

Over the past couple of years there has been a large influx of Objective-C developers. Some are coming from dynamic languages like Ruby or Python, some from strongly typed languages like Java or C#, and of course there are those who are new to programming altogether. But this means that a large number of Objective-C developers haven't been using it for all that long. When you're new to a language, any language, you focus more on fundamentals like the syntax and core features. But it is often the more advanced, and sometimes less well used parts of a language that really makes it shine.

So if you're in the tech world you may have heard that several small iOS developers have been sent legal papers by what is commonly known as patent troll, asking for money for a patent that apparently covers In App Purchasing. There are lots of questions, people are angry and as usual patents are being berated.

We all hear about how we need to make our applications more concurrent. There is no longer a free lunch for software developers, where processor cores will get faster, giving us a performance boosts for free. Instead we need to try and run more code in parallel.

Schemes are one of the most interesting new things in Xcode 4, but also one of the hardest to get your head around at first. This guide will help you understand what schemes are and why they are useful.

It can be hard to find your way around Xcode 4 at first, especially coming from Xcode 3. This is a quick start guide for how to find various Xcode 3 items in Xcode 4.

So it is finally here. Xcode 4 has been released into the world and we are now allowed to talk about it. As my review of Xcode 3.2 went down really well I thought I would have a go at reviewing Xcode 4 in depth. I'll also be publishing other posts over the next few days going in to some of the bigger changes since 3.2 in more detail and hopefully helping you migrate. I've also put in radar numbers for all bugs and feature requests, so you can file duplicates or so any of the Xcode dev team reading this can find them. So without further ado, what is new in Xcode 4?

This is a blog post I've had on my "to write" list for a while. At the end of December Buzz Andersen posted a link on twitter that outlined why he doesn't feel comfortable with Pair Programming or the Agile ideal. A conversation followed between several developers, including myself, which was nicely archived by Manton Reece using his Tweet Library app. I recommend reading through the archive to get an idea of what was said.

I've just finished watching David Heinemeier Hansson's keynote talk at RubyConf. It's a great talk about what makes Ruby great in his eyes and why he hasn't bothered learning other languages since discovering Ruby. There are some things that I disagree with or that contradict each other (at one point he says Ruby protects you from pointer arithmetic, but later that he likes Ruby because it doesn't stop you from doing things even though they can be dangerous if used incorrectly) but on the whole it's well worth watching.

So I read through the slides of a talk recently, by the incredibly talented Anna Debenham. The talk is about the state of web education in schools. It is an incredibly good talk and thankfully there is a video of another talk by Anna that covers pretty much the same things here, which I highly recommend you watch. The thing is, what Anna says about web education equally applies to any form of software design and development. The education system teaches it badly, all the way from primary school through to university. They are either too theoretical or too outdated.

So… that Mac App Store thing. I've been wanting to write up my thoughts on it for a while but just haven't found the time or drive to. Then I read this post by Marco Arment. It's an interesting read, but is from the perspective of an iOS developer and I can't say I agree with much of it.

It's no secret that I'm not a big fan of Ruby's syntax. I've grown to love Ruby's functionality and I would like to see language support for some of it in Objective-C (symbols, non-alphanumeric method names and modules/mixins come to mind). I'm also not too opposed to the syntax of Ruby per say. It is concise and fairly readable.

I put my old iMac for sale on eBay yesterday. A few hours after it going on sale, I saw that someone had bought it at the "Buy Now" price. I got a bit suspicious as they had only signed up that day and had no feedback. My suspicious were confirmed this morning when I received emails from eBay saying that the buyer had left the site. All credit to eBay, I was able to get through to someone on the phone within a 90 seconds of calling (despite them saying there was a large number of calls) and get my fees refunded so I could re-list it.

There is a misconception that in order to get the effect of the retina display on the iPhone you need a display that is 326 dpi (dots per inch), regardless of the device.

My health hasn't been all that good the past 3 years. Up until 4-5 months ago I was suffering from a mental illness. And now I have a physical illness which is technically even worse than what I had before. Oddly enough though I've been quite open about the physical illness and fairly quiet about the mental illness. This blog post will change all that and give details about them both, what they are, how they affect me and how you can get help if you need it

OK, let's be frank. 32 bit is dead on the Mac. Apple cut out most of their 32 bit users when they dropped PPC support in Snow Leopard. Those that remain are 3-4 year old machines, so are likely to be replaced in the next 12 months given the 3-5 year upgrade cycle most people have. 32 bit is a legacy platform and should be treated as such.

So yet again I saw a tweet about the impending death of the Mac in favour of the iPad and yet again I feel the need to blog my answer rather than have 10 conversations about it on Twitter.

There was a short twitter conversation between @rentzsch and @joehewitt last night about the decline of the Mac market due to the iPad. It was started by this tweet:

"If the Mac market is going to shrink to the size of the current market for Mac Pros, perhaps that will be the only model they keep alive?"- @joehewitt

I don't agree with these tidings of doom for the Mac. The fact is, a desktop computer is still the best job for many tasks, and a touchscreen tablet wont replace them unless it becomes a desktop computer. The iPad form factor/input mechanism is inherently flawed for certain tasks, where the desktop excels at them.

Welcome to my new personal blog. I've decided that I need a place to write my thoughts down, rather than spewing them over twitter or IM or other more realtime forms of communication where my hands type faster than my brain works.