Tag Archives: Development

UIKit for Mac

mar·zi·pan
[mahr-zuh-pan]
noun: marzipan

  • 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.

In the episode Marzipan: Apple’s Next Big Software Thing! of Rene Ritchie’s VECTOR he discusses Marzipan with a lot of well known developers and writers. None of the folks go as far to think Apple could be making a monumental leap forward with Marzipan. What if Apple goes all in on a brand new framework completely written in Swift? I know it’s not likely to happen, but what if it does?

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.

Duct tape. Fixer of all thingsOf 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

Eat your own dog food.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.

UIAlertController
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.

What Ifs and Why Nots

Apple announces new MacBooks to the world this week and geeks aren’t overly impressed. It’s OK. My gut reaction wasn’t overly positive, but what the heck did I expect? There were enough leaks in the press to warn us about what to expect.

As a Professional Software Developer I don’t need a thinner, lighter, laptop with an integrated touchscreen on the keyboard, but it also doesn’t cause any damage to have those things. I am definitely more interested in having a great piece of hardware that serves my needs.

My Needs

Will write C/C++ for foodI’m not obsessed with the looks of Apple products. They are beautifully designed. I’m a bit more pragmatic. I want my hardware to be fast and dependable. Apple makes fast and dependable hardware. I will never understand their obsession with “thin and light” but that’s ok. It’s their thing.

In the end I’ve been very happy, and I’m still happy, with my late 2011 15in. MacBook Pro. Work provided me with a 2014 15in. MacBook Pro and I can imagine it will work just fine for years to come. At some point down the road macOS will outgrow the hardware and I’ll upgrade. Until that day, I’m fine with what I have.

What If?

It’s too early to tell but what if Apple is in the middle of a transformation from macOS based devices to completely iOS based device? If we were to base that question solely on this weeks announcements it might be a completely reasonable guess, but what if they’re not done announcing new macOS based devices?

It sounds like, based on recent reporting, that Apple is out of the display business. I know that’s sad for a lot of folks, but for me it adds a ring of truth to the idea of Apple moving away from the desktop. Based on that one rumor I half expect Apple to mothball the Mac Pro, Mac Mini, and iMac. What if they do that? It’s fine, they don’t need to make desktop devices any longer. They’re moving to a completely mobile world driven by iOS and the iPhone. Yes, people do real work using just their iOS devices.

That brings us to this; Apple will continue to push the iPad as a professional device for most people. They concede the desktop to everyone else, including Microsoft (who owns the productivity worker space anyway.) That leaves them with the consumer and prosumer markets, which is a perfect fit for them.

Where does that leave professional developers, designers, illustrators, and artists of all kinds? Like I said before, I don’t need a Mac Pro to do my job, but some people do, or at a minimum believe they do (which by extension means they do.) We’ve seen some cases in the high end video production world where shops have abandoned the Mac in favor of more powerful Windows based computers. Designers, illustrators, and artists have the option of the iPad Pro, MacBook Pro, and Microsoft’s recent entrance into this market with Surface Studio. Will a lack of a Mac desktop offering hurt these professions? In some ways it probably will, in others I honestly believe folks will adapt if the software can meet their needs head on. As far as high end workflows go, I’m not so sure. What do folks at Pixar use? Are they completely tied to their Macs or do they depend on Cintiq’s for their daily workflow? I don’t have the slightest clue, but this is where Apple could really disappoint a professional market. I’d love to hear from someone inside Pixar, ILM, Disney, or DreamWorks to see how this could effect them. Remember, outside of the software development and power user communities, most people see their computers as a carpenter would see their hammer. It’s an essential tool and they may have a preference, but a compute is a means to an end.

Why Not?

AHHHHHH!If Apple decides to abandon the desktop in favor of an iOS world, why not create a hardware specification to allow licensed third-party hardware vendors to sale computers with macOS? At a minimum spec out supported hardware configurations and allow people to buy a macOS license to run on their Hackintosh computers.

Another controversial why not. Why not port Xcode to Windows and offer an alternative, lesser expensive, choice to developers that could also let people buy super fast computers to code with? I know, it’s a crazy idea, but as of this writing I’d prefer a Windows computer over an iPad as my primary development computer if I couldn’t get updated desktop or laptop hardware directly from Apple.

Since Microsoft is moving to LLVM why not get Objective-C and Swift running in that environment and provide the iOS simulator on Windows? This also seems like a decent alternative to an all iPad development environment.

All crazy ideas, I know, but things I think about.

Then again, Apple could surprise us in the spring with a brand new Mac Pro and iMac that blows all these crazy ideas right out of the water.

Core Intuition(@coreint) 209: We Need A Grand Gesture

I’ve been listening to Core Intuition with Daniel and Manton for a very long time. Being new to the Apple and iOS ecosystem it’s nice to hear from guys that have been around for a while. They have some pretty unique insights and experience to share with those of us new to community.

I feel like it’s time for me to give back a little. In Core Intuition 209, the talk a bit about Swift. With the advent of Swift, and Apple’s deep commitment to it, it’s tough as an old-time Objective-C developer to see and hear all the attention being given to the new baby. I’ve been in your shoes.

Back in the early 2000’s as Microsoft was making a big push with .Net and C# I was still hacking away on C++ applications written straight against the Windows API. Early on I had my doubts about .Net and C# becoming the development tool of the future on the Windows platform. Fast forward to 2015 and it is the dominant development tool. It just took a bit of time for people to become comfortable with the idea and, more importantly, it took time to people to trust Microsoft was all in with .Net.

I think something Apple has done a really good job of is convincing the development community they’re committed to Swift. It’s the only development tool at Apple that has really reached out to the community. They have a weblog and just this week released Swift to the open source community. Apple is committed.

Does it mean you should run out and rewrite everything in Swift? Probably not, but that is a choice you will have to make on your own. Apple has a huge investment in Objective-C and Cocoa and even if they stopped making huge advances to either it’s going to be years and years before writing code in Objective-C is not a good idea. In fact, Craig Federighi said as much this week in an interview with The Next Web.

“Objective C is forever. I don’t think anyone should fear for the future of Objective C. We’re going to continue to support Objective C for ourselves and the developer community.”

On Core Intuition the guys each said something that really stuck accord. Manton mentioned Swift’s syntax was a bit too punctuation happy, which I can agree with, and he says it reminds him of C++, which I also agree with. In my case I actually like the C++ language, whereas Manton said he’d rather not go back to it. I would never hold that idea against anyone. It’s an unforgiving language.

Daniel mentions his reluctance to add the Swift runtime to his products just so he can include a new class here or there. I had this same feeling when adding C#/.Net code to an existing C++/Windows API application. It just felt so weighty to get such little support. In those cases I’d say why change? Just keep hammering away in Objective-C if you’re good at it and you can move to release new product quickly. When building a new product give Swift a whirl.

Another great point discussed by Daniel and Manton was how people embrace new languages and find a way to over complicate things. Think about the Architecture Astronaut. Swift brings all kinds of interesting syntax sugar to the table, but it doesn’t mean you have to use it. Start simply, experiment. You’ll find things in the language you love and things you hate. It’s true of every language I’ve ever learned. Keeping your code readable and maintainable is way more important than any syntax sugar offered by the language.

I’ve been working in Swift for the past few months and we’re doing more and more at Agrian with it. All new features are being written in Swift. The language is expressive and once you get going I think you’ll find you can move pretty quickly. We still have large portions of code in Objective-C. We’ve been selective about moving bits of that code to Swift and other parts we leave alone.

If you’re an iOS or Mac developer I recommend you listen to Core Intuition. Daniel and Manton are thoughtful and very experienced developers. Listen and you’ll learn something new.

My New Job

I’m happy to say I’ve landed a new full time iOS Development position with a great company; Agrian. They’re a smart and fun bunch focused on creating useful solutions for the Agricultural industry. We live in the great San Joaquin Valley of California, it’s the richest agricultural land in the world. At Agrian we’re “…dedicated to helping all participants in the agrifood industry to grow and harvest crops that are safe, profitable, and comply with a host of state and federal government regulations.” It’s all about making things better for farmers, which in turn, will benefit all of us.

Agrian understands web scale solutions and realizes it’s all about services. Mobile is one tiny cog in that machine and I’m happy to be a part of it.

On the technical side of things I’ll get to use all kinds of nifty stuff day-to-day. We are, of course, using a lot of Objective-C but there is a nice little mix of Swift in the code base, I’m sure that will increase as we move forward. We’re also using some very interesting frameworks. I hope to share more on those later.

The group of developers I’m working with are top notch, all of them. I hope I can live up to expectations.

Esoteric iOS

Apple Core Labs: “Since we have to integrate with multiple scanners we have to decide at runtime which scanner is being used. Using the SDK’s we could take a stab in the dark at initializing each one in turn and the one that succeeds to initialize is the winner. Not such a great way determine the one to use, but it would work.

What if there was a way to determine you had connected external devices without using a third party SDK? There is.”

I’m not sure many people know about the External Accessory Framework. If you’re working with third party devices that work with iOS give the piece a read.

Design then Code

Design then Code
Design then Code: “Building iOS Apps From Scratch is an introduction to Objective-C and Cocoa for first-time coders. It explains Obj-C’s unique syntax, the Cocoa frameworks, creating and using objects, Model-View-Controller, and how to build an app’s interface. This is suggested reading before tackling project tutorials.”

This is Mike Rundle’s latest project to help the iOS Design and Development community avoid creating Frankenstein applications. Mike’s a rare breed, he’s a great designer and he gets Cocoa and Objective-C, which makes me a bit green with envy.

If you’re a beginner, and can’t wait to build your first iOS App, you could do a lot worse than purchasing the Design Rookie and Cocoa Rookie packages together. Heck, if you’re not sure, give the free tutorial a spin before purchasing. That should give you some idea of the quality to expect.

Well done Mike!