It’s that time of year. Time for the Apple Developer community – and punditry – to make wishes for their favorite features to be added to their favorite OSes and hardware.At this point macOS and iOS are so mature I can’t think of any feature I’d like to have. I’m sure Apple will come up with something I’ll enjoy but we have so many features I’ve never touched as a developer. Some because I have no real need for them in my apps and some because I just don’t know they exist.
The only thing I keep coming back to is macOS on iPad. Why?
Well, now that macOS can run iPad apps it seems a natural fit to put all that power and openness on a smaller device. I can see walking into my office with my iPad, sitting it in a VESA mount next to my VESA mounted display, having it connect to my keyboard, monitor, and mouse and off we go.
It would take some time for Apple to make it work, no doubt, but iOS and macOS already share a lot of code. There will be plenty of things to sort out, like touch, but it’s not like they couldn’t do it if they wanted.
Consider swiping between the Mac desktop and Launch Pad. Launch Pad could act as you iOS springboard for all of your iOS apps. Perhaps you group them together or maybe the OS is changed to do something special for you. That way you could put yourself in that mode when you’re not docked and use all of your favorite iOS apps then move to the Mac Desktop when you’re docked and need Xcode to do your dev work.
It feels like a natural progression to me and I definitely do not agree with the punditry about keeping iPad pure. Offer two versions. A Pro model with iPadOS and a Pro model with macOS. Problem solved.
a sweet, yellowish paste of ground almonds, sugar, and egg whites, often colored and used to make small cakes or confections or as an icing for larger cakes.
a new Apple Framework for building Mac and iOS Apps from the same source code.
A unified Apple Framework makes sense. By this time AppKit is fairly old, it began life at NeXT and moved forward as Apple’s new framework on macOS. When Apple created iOS it made sense to reconsider the user interface and user experience for a touch based interface. Having support for mouse clicks and menus didn’t make a lot of sense for something so small controlled with your finger. Enter UIKit.
To say iOS became a shooting star, Apple’s crowning achievement, would be an understatement. It’s wildly popular amongst users and developers alike. So much so Apple has kind of pushed macOS into the background and allowed its younger brother to take center state. It’s not that macOS isn’t popular — because it is — it’s just that iOS is much, much, bigger than anyone could’ve estimated. As a result Apple spends most of its time working on iOS, or at least it seems that way.
Obviously that would be hugely upsetting for the Mac and iOS ecosystem. But on the flip side it would give developers a clean slate to work with. Something designed to work for touch and mouse and keyboard input. It would give Apple the chance to shake off years cruft and reimagine applications and frameworks without the constraints imposed by Cocoa or Cocoa Touch.
Am I crazy? Yes, a little. I know current developers — especially Mac developers — would lose their minds. It would be the second time Apple changed direction on them in a potentially radical way. This wouldn’t be quite so egregious. The move from Mac OS 9 to Mac OSX was monumental. A brand new OS and a brand new way to code, not easy to adjust to after years of working with an OS and API. Carbon eased folks into it, but the transition was still extremely difficult for some development shops, like Adobe.
Of course they don’t have to go all in. I doubt they’d be that extreme. There are simple things they could do to unify Cocoa and Cocoa Touch. An extremely simple example I can think of is unifying NSColor and UIColor. Over time we’ve seen some text attributes move to their NS* counterparts, why not start with the simple things and work down the stack?
I also don’t consider going from iOS to macOS cross platform. I know they’re slightly different but they are in the same family. If you’re doing iOS development macOS should feel somewhat familiar to you. Sure the controls are different on the platforms and there’s the matter of touch vs. mouse driven, but I believe calling Cocoa based applications cross platform between Mac and iOS is a bit of a stretch. If you’re taking one set of code from iOS to Windows that is what I’d consider cross platform.
Post WWDC 2018 Thoughts
I penned everything above quite a while back, March 11, 2018 to be exact.
While on stage at WWDC Apple announced UIKit for Mac. Four UIKit for Mac applications will ship with macOS Mojave this fall; News, Stocks, Home, and Voice Memos. This is great news for anyone interested in bringing their own iOS Applications to macOS. It means Apple is dogfooding UIKit for Mac while it’s in active development. From all reports it’s really rough around the edges but we can all hope some of those edges are smoothed out before Mojave makes its debut but it’s ok if the applications and framework are a bit rough at first. Why? Apple said on stage UIKit for Mac wouldn’t be generally available until 2019 and that it was a multiyear project. This tells me we should expect a gradual move of UIKit downward into AppKit until UIKit either becomes a part of AppKit architecturally or the Mac specific bits of AppKit become a part of the “new” UIKit for Mac.
In many ways it feels like UIKit for Mac is the right direction. It’s been running on macOS for 10 years. If you’re a developer you’ve used the Simulator everyday to run your iOS Apps on your development machine.
Definitely not what you want to see on your Mac
Any developer will tell you shipping software is difficult, especially if you’re driven by deadlines and not feature sets. Given Apple have already announced four applications shipping with Mojave they’re going to have to make really tough decisions to make sure these select applications are ready by fall. It seems reasonable to expect these first UIKit on Mac applications will have a decidedly wonky feel, not quite native. There will be telltale signs, little things, that drive native app seeking people crazy. Things like seeing a UIAlertController instead of an NSAlert when an app needs to inform you of something or ask a question. It makes the application feel unnatural.
Getting an error on your Mac can be frightening but at least this alert feels like it belongs on the platform.
At the beginning I’d expect UIKit for Mac to either reach down into AppKit to do the work or reach under the hood and use the same lower levels AppKit uses. Conceptually this is how UIKit living on top of AppKit looks. It’s a way to bootstrap your new Framework into being. Leveraging what AppKit already does seems a reasonable way to just make it work.
UIKit living off of AppKit like some kind of digital vampire.
As time goes by I would expect more of AppKit to move upward into UIKit. UIKit becomes the new preferred framework for building applications on Mac. Maybe it gets a new name? Maybe not? As that transformation begins taking shape we’ll see UIKit itself transform to feel native on each platform. Mac apps will feel like Mac apps and iOS Apps will feel like iOS Apps. It’s not rocket science. Applications for each OS should feel like they belong. No compromises. Hell, we can write Electron Apps if we want compromise.
UIKit consumes the heart and soul of AppKit becoming the ultimate application development platform for Mac and iOS Apps.
As Craig Federighi pointed out on stage at WWDC this is a multiyear effort. Expect things to be ugly at times from the user perspective and the developer perspective. In fact I expect it to be the development effort going forward for iOS and Mac UI Frameworks. Until — of course — the next shiny framework comes along.
Dave Rogers: “Allow me to vent my spleen here briefly on what an utter piece of crap Apple’s Photos app is on iOS, and the Photos iCloud architecture. The MacOS app is slightly better, but it’s still crap too.”
Being a fan of Apple can be frustrating in the modern era. It’s no longer focused on creating the best tools for professionals like it once was. We’ve entered the 800lb Gorilla phase in Apple’s life. They’ve switched focus to creating the best experience for the lowest common denominator, they are now the everybody company. This isn’t a bad thing overall, it’s just different. Apple still creates the best integrated hardware and software experience on the planet, but it’s aimed squarely at the masses, not professionals or, as in the case above, power users. We’ve seen this with the abandonment of Aperture and the lack of hardware upgrades in the Professional Mac hardware lineup (the flip side to this is my 2011 MacBook Pro is still plenty of computer for iOS development.)
The land rush that has been iOS App Development is beginning to lose its luster. The market is full of crummy games that milk users for cash to buy their way past levels. That market is really designed for the attention deficit. I’d love to find the time, money, and energy to focus on the Professional Mac using market. I really believe there is something to be had there as a developer and a user.
If you’re a developer in the Apple ecosystem you’ve no doubt heard of Swift, and could be developing with it every day.
I work for a little shop focused on Agronomics Software and Services. Our service is like many gigantor services in thee market; a website with a backing REST based service. It’s a magical cloud!
We also develop a mobile client for iOS. Our products are Objective-C based but recently we’ve been writing new features in Swift.
Swift is a really nice language. It takes some getting used to and the syntax is super sugary. As an old C/C++ developer a lot of it feels right at home. We get to trade a dynamic language for strong typing, which doesn’t bother me in the slightest but might bug died in the wool old-time Objective-C developers. Anywho, suffice it to say I’m enjoying it, and I hope to develop in this language for many years to come.
You’re probably saying “What’s your point, man?”
What I’m trying to say is I hope Apple goes whole hog and gives us a new framework for application development. That’s right, leave Cocoa as it is, put it in maintenance mode and do everything from this day forward with a new set of frameworks built entirely in, and for, Swift.
I also hope Apple can bring more of the concepts learned from UIKit back to the Mac. We have a wonderful set or portable API’s with Cocoa, but the Mac feels a bit neglected. If a new set of frameworks were developed Apple could start fresh, leave out the cruft, and give us new frameworks built to take advantage of Swift’s language features.
I would imagine this idea makes app developers cringe. What about all those years invested in Cocoa? For years to come I would imagine Cocoa apps would receive plenty of support and still be first class citizens. Remember what Adobe went through to bring Photoshop to the Mac when Carbon was dropped? Yes, it can be painful, but knowing ahead of time Apple will eventually pull the plug on Cocoa would be helpful, if they ever feel like taking on such an ambitious project.
In 2000 (I think that’s the correct year) Microsoft brought us .Net with the C# programming language at a time when the Windows API (Win32 API) and C/C++ were the primary way to create great native Windows apps. This is what we used at Visio. Lots and lots of C/C++ with the Windows API, later on we introduced MFC into the mix, and finally after bein acquired by Microsoft we integrated Office shared components (MSOx.dll’s.) Microsoft to this day still writes in C++ for its Office apps but most development outside is now done in .Net in C# — I’m sure Microsoft is doing plenty of work in C# and .Net. It’s a very powerful framework and programming language and is getting the lions share of the attention. It was a big risk, but it has paid huge dividends for the Windows ecosystem.
This can be done, is my point. Apple did it with Carbon to Cocoa and Microsoft had done it with the Windows API to .Net Framework. It feels like we are primed for a new Apple Framework that embraces Swift.
Please note, I’m not suggesting that Apple should completely abandon Cocoa. If this type of change happens maybe they can keep parity between the two for a while to give developers time to switch. Remember, Carbon was released in 2000 and finally fully deprecated in 2012, it became way less useful in 2007 when it was not updated for 64-bit applications. Depending how you look at it, Apple supported Carbon for seven, or 12 years. If they allowed for a five year overlap of feature support before fully deprecating Cocoa they could allow developers to move into the new, completely Swift, framework.
Recently we have seen Dropbox fully embrace Swift. With the Dropbox V2 API the Dropbox team has dropped support for Objective-C. That speaks volumes. It’s obvious they feel strongly about the future of Swift.
Is a movement to an all Swift Apple Framework in our future? Your guess is as good as mine, but it is obvious Apple is embracing Swift as its language of choice for future software development.
Cult of Mac: “We don’t believe in having one operating system for both mobile and PCs (like Microsoft),†he said. “We think it detects from both.â€
I got one serious answer and some fun poked at the question, which is fine, but I think it points to a real problem on the Windows Desktop.
Has Microsoft given up on native applications at a time when native on Apple Platforms and Android have never been more popular?
On Apple Platforms we have clear, well defined, native development tools for creating serious desktop applications. Think of apps like Photoshop, or more modern takes on graphics like Sketch, Acorn, Pixelmator, or OmniGraffle. Most of these applications are written in Objective-C against Cocoa (Apple’s Framework for writing applications.) Sure, Photoshop is the old guy in the mix and is built on a custom framework written in C++ that communicates down to Cocoa (and possibly some Carbon API’s?) also worth noting, with the exception of Photoshop, not a single app mentioned above is cross platform (I’m not including Mac to iOS as cross platform, many of the API’s are the same and the act of going from one to the other is much easier than going to a completely different platform.)
All that brings me back to the question of developing native applications in the vein of Visio or Photoshop on the Windows Desktop. I’ve seen plenty of talk about creating Universal Apps, but those seem geared toward a lighter weight style of application, singular purpose apps focused on lightweight tasks, like Twitter or Facebooks clients, not hard core productivity applications that need to perform well and provide their best experience on the Desktop.
We still have Visual Studio, C++, and the Windows API, as a development platform but it feels somewhat abandoned. I know the folks working on the C++ compiler would probably argue against that statement because Microsoft is definitely investing in C++, but what about OS level API’s? That is the level that sort of feels abandoned. We have WinRT today, which seems like it might be part of the story for native desktop development, but do you mix and match that with the Windows API to build a great native application, do you use WinRT alone, or do you just continue to plug away with the Windows API?
It seems that apps built for the modern Metro look should use WinRT? Based on that it seems the old tried and try combination of C++ and the Windows API would still be the best choice for hard core desktop development.
But what about C# and XAML? Maybe those are a good choice for serious desktop development? I’m unclear on that subject. I’ve heard that the Visual Studio IDE was rewritten in C# for Visual Studion 2012, but I don’t know if that’s true or not. If someone reads this post and can point to MS Office, Visual studio, or Photoshop class applications written in C#/.NET I’d love to hear about them. Worth noting is the wonderful toolset by the folks at Xamarin, it makes C#/.NET app development truly cross platform.
Being a long time C++/Windows API guy I still gravitate toward that toolset. Hey, I have a lightweight class library I wrote in 1993-94 that still works today; it builds with Visual Studio 2015 and runs fine on Windows 10, but it could certainly use some refactoring given the state of modern C++. Think C++14.
I’ve been working on a cross platform project recently using Qt, which has me think about portable C++ for Mac, iOS, Windows, and Android. Given C++14 as a starting point for most OS level services; file I/O, threading and synchronization, etc, what would it take to build a modern C++ library that handled native user interface creation and interaction and didn’t feel too constraining on the platform? Remember, most cross platform tools come at a price. They’re always a little behind, they tend to be least common denominator, and can feel non-native. Qt, for instance, doesn’t use native controls on Windows (NOTE: this may not be true today. This was true around 2008, the last time I looked), I find that terribly annoying. I’m sure any Mac, iOS, or Android developer worth their salt would also find it annoying.
A nice new C++ framework for building native OS level user interfaces using modern C++ as a base would be great to see. I really wonder how long it would take to build such a thing?
There was a lot of buzz generated around the discovery of a private framework, called UXKit, that shipped with Apple’s upcoming Photos for Mac app. Like many others I initially thought “It’s about time.” Then I started thinking about the transition that happened when Microsoft created C# and .Net. At the time we had the Windows API and our trusty C/C++ compiler. At the time .Net shipped in early 2002 we were still building desktop applications, the web was moving forward, but not at the pace it is today. Microsoft shipped WinForms, which was pretty much a straight wrapping of the Windows API’s for .Net developers. The point is, Microsoft gave developers a way to do stuff with the new language and runtime that could get them up and running quickly. The environment was different, but the API’s felt familiar.
Moving Forward
In 2006 Microsoft released a new framework called WPF (Windows Presentation Foundation.) This new framework made use of DirectX so rendering the user interface was hardware accelerated, along with other nifty stuff. As far as I know this was the last major framework Microsoft created for desktop developers. Since that time web development and Surface (Metro) seem to be their primary focus. (Someone please correct me here, if this is not accurate. I’m not that dialed in to Windows desktop API’s any longer.)
The point is, Microsoft went through this weird transition from the Windows API to a intermediate (WinForms) to their final desktop UI framework over the course of four years. Creating new technologies and frameworks is hard. They take time, but Microsoft is good at API’s, and they’re very good at maintaining them and providing developers an upgrade path. This is, I believe, where Apple is today. They’re in that awkward period between AppKit and whatever is next.
Enter Swift
In the summer of 2014 Apple gave developers a great surprise at WWDC. They introduced us to a new language; Swift. Since that time Apple has created a weblog dedicated to the language and shipped Xcode 6 with full Swift support. At this point in time it seems like Apple is pushing hard for iOS and Mac developers to adopt Swift as their primary development language. They seem to be “all in.”
Get to the point
Long story short. Do I believe UXKit is a future version of UIKit for Mac development? No, I don’t. I believe it’s a private framework created by the Photo’s team (or another team) to allow them to share a bunch of code with the iOS counterpart. It makes sense. Apple traditionally operates very lean. They have very small teams, so they need to work as fast and smart as they can. If they have a framework that allows them to share more code, it may allow them to move more quickly.
Ultimately I believe we will get an entirely new framework. Built from the ground up using Swift. I suspect that framework will aim to share code between iOS and Mac where it makes sense, and diverge where it doesn’t. The overall feel will be the same for both platforms. It will be unified.
I love thinking and writing about future technologies. I’m rarely ever right in my guesses (see my musings on WinRT), but it doesn’t stop me from dreaming.
Kevin Hoctor: “The irony is that I’m the one always preaching to others that they need to be passionate about what they do. Don’t settle for a paycheck. Don’t work at a place that makes you want to rush home and down a bottle of vodka to balance out the day. Yet, here I am doing exactly what I’ve told my kids not to do.”
Kevin made the transition from frustrated Windows developer to Indie Mac developer and is still going strong. About six months after the above post Kevin shipped Debt Quencher 1.0. I don’t think he’s looked back.
Mike Ash: “That, in essence, is what ARC is. The memory management rules are baked into the compiler, but instead of using them to help the programmer find mistakes, it simply inserts the necessary calls on its own.”
Reference counting is a pain in the keister, until you understand the rules. ARC is going to become an important tool in the quest to creating error free code. If you’ve ever written ref counted code you know how careful you need to be so you don’t leak memory or double-release something and cause a crash. It can be frustrating if you don’t pay attention.
This is a welcome change and one I’m looking forward to.
I think it’s time for an RxCalc refresh anyway. Plus some other nifty things I’ve been working on, that will definitely be ARC’d and Mac OS X Lion / iOS 5 only.
At this point macOS and iOS are so mature I can’t think of any feature I’d like to have. I’m sure Apple will come up with something I’ll enjoy but we have so many features I’ve never touched as a developer. Some because I have no real need for them in my apps and some because I just don’t know they exist.
Of course they don’t have to go all in. I doubt they’d be that extreme. There are simple things they could do to unify Cocoa and Cocoa Touch. An extremely simple example I can think of is unifying 
I penned everything above quite a while back, March 11, 2018 to be exact.
Being a fan of Apple can be frustrating in the modern era. It’s no longer focused on creating the best tools for professionals like it once was. We’ve entered the 800lb Gorilla phase in Apple’s life. They’ve switched focus to creating the best experience for the lowest common denominator, they are now the everybody company. This isn’t a bad thing overall, it’s just different. Apple still creates the best integrated hardware and software experience on the planet, but it’s aimed squarely at the masses, not professionals or, as in the case above, power users. We’ve seen this with the abandonment of Aperture and the lack of hardware upgrades in the Professional Mac hardware lineup (the flip side to this is my 2011 MacBook Pro is still plenty of computer for iOS development.)
I would imagine this idea makes app developers cringe. What about all those years invested in Cocoa? For years to come I would imagine Cocoa apps would receive plenty of support and still be first class citizens. 
All that brings me back to the question of developing native applications in the vein of 
There was a lot of 
