Category Archives: Apple

Old Devices

I don’t like to install beta versions of iOS on my daily driver device so I tend to use old devices I have left around from years past. This year, however, I didn’t have a device capable of running iOS 12, so I bought a used one on Letgo.

For $60US I was able to purchase an iPhone 5s with a cracked screen that works just fine. I decided to pickup a new screen from iFixit for another $40US. All in, $100US and I have a great new test device. It actually runs iOS 12 really well.

So, if you’re short on cash, try a used device for testing.

Robbing Apple

Gizmodo: “On July 7, four thieves reportedly nabbed over $27,000 in iPhones and MacBooks from the Fashion Fair Apple Store in Fresno, California. Surveillance footage of the robbery shows the men hurriedly entering the store, walking up to display tables, and grabbing a bunch of devices as customers and employees stare on with placid astonishment.”

Sigh. This just had to happen in Fresno, didn’t it?

iPod Touch

Why doesn’t Apple improve on the iPod Touch every couple years? Why not take older chip sets — maybe a model from last years iPhone — and leave the form factor alone? Just keep stuffing updated tech into the existing design.

There are folks that can’t afford to buy their kids an iPhone but the iPod Touch may fit nicely into their budget.

Yep, it's a rooster.As a developer this is also a nice machine for testing. The only issue I see is it hasn’t been revved in a long time. It’s still using an A8 processor but it is still slightly ahead of the iPhone 5s which uses an A7. that’s important because the iPhone 5s is the lowest end iPhone that supports iOS 12. That means we could get another couple years use out of the current generation iPod Touch.

The iPod Touch with 128GB of storage sells for $299US.

Fingers crossed Apple updates it soon.

The Gorilla Arm Myth

Harry McCracken: “And for close to seven years, I’ve used an iPad in a keyboard case as my primary computing device. In all the years that I’ve been raising my arm to the screen to tap icons, scroll through text, and perform other actions, it’s never felt like an ergonomic burden, or even something I give much thought to one way or another. There are certainly instances when using a mouse or trackpad might have felt easier—for selecting large chunks of text, for instance—but that has less to do with inherent problems with touchscreen computing than it does the design of iOS and iOS apps.”

A wonderful bouquet of flowers.

I like to visit a local Starbucks when I’d like to get out of the house while working. When I do I have a habit of counting the devices I see around me and what type they are. Are they MacBook’s are they PC’s? I’ve run across a fair number of folks using touchscreen Windows boxes, most notably Surface Pro’s. They’re great computers. The display is basically a tablet with a detachable keyboard. Think about iPad Pro with an Apple Keyboard. Yeah, just like that, but in this case the computer is running full blown Windows. I know it’s blasphemy to you like Windows in the Apple ecosystem, but I really do like the Windows Operating system and Microsoft’s developer tools. They’re both top notch. If I were writing Windows applications everyday I’d pick up a Surface Pro as my daily driver. It would be powerful enough for building code and I could detach the keyboard and use it as a tablet. Oh, did I mention the Surface Pro has a pointing device? That’s a big bonus for fine grained selection.

In conclusion you can lump me with the “I’d love to see a MacBook Pro with touchscreen or a new product based on iOS that is deeper, richer, than ever before” crowd. A version of iOS with a trackpad and mouse pointer that can run Xcode — optimized for iOS — and other tools.

I’d call it iBook.

A Rainbow of Color

A Rainbow of ColorSix Colors: “Now, a new report suggests that Apple may once again veer into color territory, with the current metallic options joined by different shades, including blue and orange. Frankly, it’s about time.”

If Apple drops an orange MacBook Pro on the market, oh my. Take my money, as long as the keyboard works.

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.

MacBook as iOS Device

Bloomberg: “Starting as early as next year, software developers will be able to design a single application that works with a touchscreen or mouse and trackpad depending on whether it’s running on the iPhone and iPad operating system or on Mac hardware, according to people familiar with the matter. “

This is something I’d welcome. I’d love to see a 12-inch MacBook sized laptop running iOS that allowed touch input and mouse input. That would be amazing.

I know that’s not what the article says, but it’s something I’ve been thinking about for a very long time. I think Microsoft Surface Pro is a wonderful computer and I don’t see why Apple couldn’t make something like it. Of course there will be much gnashing of teeth, but it seems an obvious compromise for a hybrid experience.

Here’s hoping.

Guess I’d better hurry up and finish up my Mac App so I can get started on the iOS version?

Apple Watch as an Heirloom?

When the Apple Watch was announced I saw some pictures on apple.com that gave me hope Apple would make the guts replaceable. (If someone knows of a picture showing an exploded view of the Apple Watch I’d love to hear about it.)

For some crazy reason I thought it could become an heirloom, like the watches my grandfather passed to me. Those watches are very special to me. They’re physical objects that still work and remind me of my grandpa.

When Tim Cook said the Apple Watch was “The most personal device we’ve ever created” I took him at his word. It is a very personal device to me. I have great affection for all of my Apple devices, but they all feel like tools compared to the Apple Watch.

I still really want a device I can wear for the remainder of my life and pass it down to someone else and have it continue to function. This is something Apple could do, if they wanted. I know I’m asking for a lot. But, if I can’t do this it means the Apple Watch is really an expensive throwaway item. Because it does feel so personal, I hate that idea.

I think the first test of this devices longevity is approaching. The battery is not

Muddy Watch

so great. It managed to last for over two years but now dies mid-afternoon. At some point I’ll take it in and hope I can get a replacement battery. I don’t want a new watch, I just want a new battery. When my iPhone 5c’s battery went bad they just replaced the entire device, which was fine with me, but I feel a need to keep my watch. The face and body are scratched and that makes it really unique to me.

If there is no way to replace just the battery from now until I croak I’ll just switch back to one of my many analog watches and keep my Apple Watch Series 0 as an artifact of an interesting time for Apple.

MacBook Reviews

Joe Cieplinski: “Here’s the thing about this MacBook: I’m drawn to it. I don’t know if it’s the small size of the thing that just makes it more lovable, but I’m already finding more excuses to use this machine than I ever did with my 13-inch MacBook Pro.”

Casey Liss: “I haven’t regularly handled a full-size iPad since the iPad 3, but the MacBook feels to be roughly the same size in-hand. In actuality, the MacBook is 150% the weight of the iPad 3, but the fact that I’m even making that comparison should indicate how light it feels.”

For these two it pretty much boils down to size. It’s the laptop version of the iPad. Compact, light, easy to carry anywhere. That convenience comes at a small price — it’s not a powerhouse.

If you code for a living and can only afford to purchase one computer make sure you consider a MacBook Pro before pulling the trigger on the MacBook. Read Casey’s piece. He uses this device as a kind of iPad replacement. It’s not meant for serious development work, at least for him.

I’ve heard the MacBook called the ManagerBook. That seems, based on these reviews, to be fairly accurate. It’s a super usable, fun, portable computer that could be a great choice if you have the luxury of owning more than one device.

I could see purchasing one of these for my wife. She’s a full-time iPad Pro 9.7 user and on rare occasion she pulls out her ancient MacBook to do something like rip music to her collection. She doesn’t need a full computer often but the need does arise.

On the flip side of all this praise for the MacBook I have a good friend recently return his MacBook and pick up an older MacBook Air because he couldn’t get past the key travel on the new MacBook keyboard.

You win some, you lose some.

Scripting iOS

Last week Apple acquired automation workflow application Workflow. Of course there was a nice buzz around it and it was a big topic of conversation on various podcasts and websites.

This, of course, got me thinking about automation. I’ve always been a fan of open API’s and the ability to automate applications. We’ve also seen recently that Omni Group is opening up OmniGraffle to automation via JavaScript.

Back in 2010 x-callback-url was created as a way to allow applications to call into each other and return results so you could chain together calls to build custom workflows. Apps like Launch Center Pro and Workflow took advantage of x-callback-url to let you build those workflows and execute them. Now we have a bonafide standard, without a standard. The app ecosystem found a way to support automation without Apple’s help.

I’ve used Launch Center Pro but until recently I’d never used Workflow, and it’s pretty amazing. The Workflow guys did an amazing job creating a drag and drop UI for building what amounts to a program. Well worth a look.

So, this brings me to what I’ve been thinking about over the past few days. Given x-callback-url and App URL schemes in general it would be extremely cool to use those to create object hierarchies using JavaScript. Why JavaScript? Well, it’s native to iOS and applications can use the runtime. Given the advances made by the Workflow team why not take it one step further?

Allow applications to specify a  Scripting Dictionary or Type Library as part of the application bundle, this should allow runtime creation of objects. I know this isn’t rocket science and it’s been done many times over.

Short of adding support to the OS it would be pretty sweet if an App like Workflow, Launch Center Pro, or Pythonista would standardize on a way to parse a URL Scheme into an Object Hierarchy.

I’m going to use Evernote, Bear, Overcast, and Arrgly as examples.

What do you mean by Object Hierarchy?

That’s a good question. Here’s what I’m thinking. Since the Apps mentioned above all support URL Schemes we can derive an Object Hierarchy from them. Basically the beginning of a URI begins with a scheme. The scheme is the name. In the case of Evernote it’s evernote. Pretty simple, right?

Given the scheme name we follow that with a path. In the case of x-callback-url based URL schemes we will skip over that part and move to the second item in the path. This will be the action, or function, or the object we’re going to execute.

evernote://x-callback-url/new-note?type=text&title=EC%203

The above URL will tell Evernote to create a new note of type text with a title of “EC 3”. If we had a way to parse that in a runtime application we could present the user with an Object that has methods that take arguments, like this.

evernote.new-note(type, title)

Let’s do a couple for Bear. First the URL Scheme.

bear://x-callback-url/create?title=My%20Note%20Title&text=First%20line&tags=home,groceries

Now translated into code

bear.create(title, text, tags)

Overcast URL Scheme.

overcast://x-callback-url/add?url=

Code

overcast.add(url)

And finally, my favorite, Arrgly URL Scheme.

arrgly://shorten?url=

Arrgly Code

arrgly.shorten(url)

Pretty simple to turn all of those into objects. When I say you can create a hierarchy it means you could, by convention, lump groups of actions into objects, or like the above examples have a set of actions that all live on a single object.

Here’s what a object might look like as a URL Scheme.

thing://x-callback-url/document/add?title=
thing://x-callback-url/document/delete?id=

That would result in using it like this

thing.document.add(title)
thing.document.delete(id)

Of course this need more fleshing out and it would require app developers to decide on a well known convention to make it work as expected, but it could be done with a bit time and effort. It could be these become an extension of the x-callback-url specification?