Archive
How To Make An iMac Pro
WWDC is nearly upon us once again. Usually this marks the software focused portion of Apple’s year. New OS’s will soon be previewed, with new APIs to play with and new features to fuss over. This year, however, there are strong rumors of new hardware. Siri-in-a-can, new Mac laptops, and iPad Pros. To be frank, there aren’t many Apple products for sale right now that aren’t due for some attention.
Apple’s recent willingness to let old hardware linger notwithstanding, it’s past time for new iPad Pros. With signs pointing to an upcoming refresh, or even re-design, there’s been a lot of speculation about what Apple could add to these new devices. One possibility the hosts of ATP were discussing was the ability to pair your iPad with your Mac and use it as a second screen. As John says, there are apps that will let you do this today, but ideally Apple could add tighter integration and make for a better experience. Imagine being able to use your Apple Pencil to draw in real desktop Photoshop. What design professional wouldn’t want that?
This got me thinking about the iMac Pro that Apple execs hinted at during the recent Mac Pro roundtable. We know that new versions of the iMac are due this year, including, in Phil Schiller’s words, “configurations of iMac specifically with the pro customer in mind”. The unanswered question is, what would distinguish a pro iMac? I’ve seen suggestions that this could mean Xeon processors squeezed into an iMac casing, or ECC ram. But those answers seemed too boring for modern Apple. What if the answer is something a little crazier.
My Crazy Prediction
There’s been a lot of discussion this year about who Apple considers a professional. For iOS, the answer is clear. The iPad Pro—the only explicitly branded “Pro” iOS hardware to date—is aimed squarely at visual artists. The Pro iPad is built around its screen and it’s support for the Apple Pencil. Apple is saying that Multi-Touch is good for casual interactions with your iOS device, but pros need more precise input. The Apple Pencil is, in Apple’s words, “the ideal tool for artists of every kind”.
Defining a pro Mac user has been more difficult. Marco Arment has discussed this at length on ATP this year, and I won’t rehash his arguments here. Instead, I just want to look at how Apple themselves presents their Pro hardware in use. On the MacBook Pro landing page, most product photographs show the laptops open and running either 2D image-editing software such as Photoshop or video-editing software such as Final Cut. (The Mac Pro page, which has not been updated significantly since 2013, does not show or discuss any software).
Apple seems to believe the following:
- Visual-design and video professionals are important markets for them.
- The Mac is an important product for these customers.
- The Apple Pencil is the best input device for visual design and video professionals
It’s possible that Apple thinks the best way to serve the customers is to turn the iPad Pro into a glorified Cintiq. But what if they’re thinking… different?
iMac With Apple Pencil Support
I’m going to start with a disclaimer. I’m not a visual artist. I don’t so much as doodle in my notebooks. So to me this is purely a thought experiment. But the more I weigh the pros and cons, the more this seems like a no-brainer.
Apple has been clear that they see no room for Multi-Touch on the Mac. Their two main arguments against this seem to be:
- macOS is designed for the precise input of a mouse and pointer, not big kludgy fingers
- The ergonomics would be terrible.
Now for the second objection. Yes, drawing on an iMac, as we know it today, would be no fun. But there are other ways to design a big screen on a hinge. I believe Apple’s designers could find a to make an all-in-one PC that allowed you to draw without gorilla-arm. They’ve already shown themselves to be flexible regarding ergonomics. Using an iPad with a smart keyboard are exactly as uncomfortable as using a MacBook with Multi-Touch, and yet that is a product you could buy today.
The success of iOS proved that removing abstraction can drastically improve user experience. Creative professionals have shown that they want to be able to interact directly with the UI, but many have also shown a preference for Macs, whether it’s because of advanced file system access and scriptability, large screens, or just because that’s what their IT departments expect them to use. They square this circle by using Wacom tablets, but that’s just another layer of abstraction waiting to be removed.
I’m not suggesting that Apple will simply copy the Surface Studio. For one thing, the lack of full Multi-Touch support would make this a completely different beast. I also think there’s a lot that their hardware designers could bring to the table. But the more I think about it, the more obvious it seems. The next step forward for the Mac is the Pencil.
Sometimes It Snows In April
It was a while before I was ready for Prince. I was still a kid in the 80’s, when Prince was still dissolving any barriers between popular music genres and the sounds he heard in his head. Michael Jackson made sense to me. There was just enough danger in Thriller to make it exciting while still being as broadly appealing as possible. Bon Jovi I got. Sure, he wore spandex, but it was in a totally heteronormative way. I was growing up in an all white shore town in 1980’s New Jersey. Even in a culture steeped in glam-metal, Prince seemed a bit scary because he wasn’t putting on an act. There was no normal guy underneath the mascara. This was Prince, all the way down.
I was like 6 years old and wanted nothing to do with him.
It wasn’t until later that it all clicked. By this time, it was the 90’s, and Prince had fallen out of favor. In fact, he wasn’t even Prince at this point. He had long since changed his name to a lazy-joke-fodder symbol. He wasn’t on the radio or MTV any more. Crazy as it sounds today, Prince seemed really uncool. This was, perhaps, the worst possible time to become a fan.
But Prince was still out there, doing his thing. Even though he had become a punch line to much of pop culture, there were still plenty of people who never lost faith. I would keep hearing musicians I loved and respected talk about how he changed their lives. It didn’t make sense. He was a dude who wore purple, sang about doves crying, and seemed doomed to be stuck in pre-grunge pop music.
Then one day I picked up a used copy of the Love Symbol Album for three dollars. I still remember putting it in the CD player in my car being blown away by My Name Is Prince, the opening track. I had never heard anything like this. The elements were all familiar, but there was something magical about the exact way he pulled together rock, funk, new jack swing, and golden era hip hop. This was no fluke. The next song was an entirely different mix but just a good. Now he started incorporating jazz. Who did this?
I became obsessed. Despite having only this one CD, I knew that I was now a die hard Prince fan. As a poor college student, I spent entire weekends scouring used CD stores to stock up on Prince’s back catalog.
In retrospect, it’s amazing that Prince was ever a pop star. He was too pure an artist. He never played it safe. He never dumbed it down. He made adult music, and he didn’t care if you liked it or not. He was a jumble of contradictions. Prince was a shy man who knew he was a fucking rock star. He was a religious man who was deeply sensual. He was a marketing genius who would purposely build barriers in front of his work.
Prince was the Large Hadron Collider of American popular culture. He would take the same raw materials available to the rest of us but would smash them together with such fantastic energy that he would consistently create something new, often dangerous, always fascinating.
I wish I could have said thank you, but it’s too late now. All I can do is keep shaking my ass, the way Prince would want it.
The Kids Are All Right
Being in your mid-thirties is a strange time. You’ve likely been out on your own long enough to no longer be one of the “kids”, but unless you’re a real hard-hearted son of a bitch, you’ve probably not reached the “get off of my lawn” phase yet, either. It’s a transition period for most people. and of course I’ve been thinking quite a bit about how and why so many people make that leap from “we are not old me. We are not worried about petty morals” to “kids these days”.
On the most recent episode of Reconcilable Differences, John and Merlin touched on this. Merlin told a story of Stephen Fry discovering Oscar Wilde as a kid living in the country, without the access to the constant stimulation that we take for granted today. Each scrap of writing he could obtain by or about Oscar Wilde was precious and and not just consumed but digested. Fry says unequivocally that he would not be the same person he is today had he grown up with Internet.
He doesn’t say this as a value judgment. It’s just a fact. In a lot of ways, we are the sum of our influences. It’s true that society could never create another you, exactly as you are. A kid growing up today would be exposed to different influences in different amounts. And I think that this is what scares older folks so much. It’s not just that young people today are raised in a different world and have different interests. It’s that this questions the essentialness of their nature. If we allow society to move away from the interests and values I hold dear, what does that say about me?
Of course, this is nothing new. In fact, it’s kind of depressing how predictable it is. Every stale joke about “hipsters” or Snapchat or whatever else else older folks don’t understand has been made innumerable times over the course of history. Only the nouns have changed.
Does this mean that all new trends are benign, kids are gonna do what they do, so lets move everyone over 40 to Florida so the rest of us can move forward already? I wouldn’t go that far. But I would ask that as you age, dear reader, have a little faith in our youth. Kids today may need a little nudge here and there, but eventually they’ll figure it out.
To Many Budgets Blues
I must enjoy sabotaging myself. That is the only logical explanation for the number of times that I have gone back to the drawing board on this app.
The basic shape of the app seemed simple when I first started working on it. Now it’s after midnight and I decided to re-write another big portion of the UI, but it’s too late to do that tonight, so I’m writing this post instead, with the expectation that by the time I’m finished I’ll have a good idea of what needs to be done. All I’m sure of right now is that the current design is not working.
The app is basically a simple travel budget. You’ve got several budget items (“Vacation”, “Food”, etc) each with an allocated budget. Initially the plan was to support multiple budgets, but that didn’t make sense. You’re only ever on one vacation at a time. So we lost the budget picker. But lets say you’ve finished your trip and liked using this system. When it’s time to travel again, how do you reset things? Maybe you want to copy this budget and reuse it. Maybe the trip is different enough to require you starting from scratch. Either way there has to be some way to start a new budget. Now the idea of multiple budgets doesn’t seem so crazy. But how do manage those? Originally I had a hierarchy of UITableView subclasses, but the user shouldn’t have to navigate through that every time they’re using the app.
So we want the app to take you to the current budget by default, but there should still be some way to manage multiple budgets. What does that look like? I’ll let you know once I have a clue myself.
Tea Leaves
Sometimes Apple appears to be so together. You get the feeling that that their events are impeccably stage managed, and every detail is thought through (despite occasional evidence to the contrary).
Apple is also a company of patterns. They tend to like yearly patterns. It made sense to expect that they would split their holiday offerings into two events, one in September and another in October. Instead, however, they decided to have one big bash this year, with focus on four(!) major product lines:
- Apple Watch
- iPad
- Apple TV
- iPhone
Notice any omissions?
As far as I can see, there are two reasons Apple chose to ignore the Mac during today’s press event.
The Optimistic Take
This event was all about new hardware. iPhone 6s. New Apple TV. iPad Pro. Even new colors of Apple Watch. However, with the exception of brief recap of watchOS 2, there was no mention of new hardware-agnostic software features. No review of iOS 9 (except for discussion of how great iPad multitasking is on that huge iPad Pro screen). Maybe Apple would have loved to talk about the Mac, but there was no new hardware ready. Intel doesn’t have the Skylake processors ready yet, so the Mac would simply not have fit in with this program. Soon enough it will be back in the spotlight.
The Pessimistic Take
Apple was focused on the future today. The Mac received about as much screen time as Windows PCs and Android phones. It is a platform that Apple supports out of obligation. Computing is now mobile (read “touch”) centric, and the Mac is no longer a first class citizen. Sure, some dinosaurs will insist on things like access to the file system and arbitrarily placed windows for the time being, but Apple is moving on.
So which of these positions is Apple telegraphing by virtually ignoring the Mac? My best guess is that there are camps on both sides inside the company. But we should be able to suss out what direction they’re going down soon enough. After all, Apple is a company of patterns.
Xcode’s Next Top Model
The idea seemed simple enough. An app to keep track of your budget on vacation. You’d launch the app and then… what? Okay, I can figure that out later.
First a bit of triage. iOS apps are generally designed around a Model-View-Controller pattern. The idea is pretty simple. Your app has to do three basic things. First, it has to have some data, stored in a predictable format (the model). It has to show you things on the screen (the view). Finally it should be able to manipulate the model and view (the controller), making sure that the right data is displayed, and that as the user manipulates the objects on screen, that’s being translated correctly back to the data.
For my needs, the model seem like the easiest bits to address, so I’m going to start there.
Well, it’s a a budget app, so there’s going to be a budget object. That can be fairly simple to start with. It’ll have a name, a start date, an end date, a total, and some line items. What do those line items look like? Well, since the user can customize them, I don’t want to get too clever. So an array of budget items it is. In Swift, your budget template will look something like this:
internal var budgetItems: [VacationBudget.NWDBudgetItem]
internal var name: String
internal var startDate: NSDate?
internal var endDate: NSDate?
internal var tripLength: Int? { get } // We can figure this out since we know the start date and end date
Wait, what is an NWDBudgetItem? Well, that’s a good question. Well, it’s gotta have a name, which can be a String, and it’s gotta have a value, which can be an Int. No, that won’t work. In America, at least, we still have fractions of a dollar to worry about (you might know them as those those little metal discs that seem to end up strewn about your home). We’ll want a better way to represent a value. My plan is to use a struct that knows how many cents it has, but can give you the amount in dollars, cents, whatever floats your boat.
What you get might look like:
public typealias Cent = Int
public typealias Dollar = Int
struct NWDValue {
internal var dollars: NWDValue.Dollar { get set }
internal var cents: NWDValue.Cent { get set }
internal var totalCents: NWDValue.Cent { get }
/// returns “\(self.dollars).\(self.cents)”
internal var stringValue: String { get }
mutating internal func setTotalCents(cents: Cent)
}
You, dear reader, may be a professional programmer and you may be looking at this and listing off the many ways in which this is a bad idea, and I’ll end up back at the drawing board before this whole thing is over. That may be the case, but hey, at least it will give me some blog fodder as I try to fix the mess I am getting myself into.
This is… well, it’s a good start. But the bigger challenge is going to be figuring out exactly how the user will interact with this thing. Next time: You Gotta Start Somewhere
Ground Floor
Estimating how long it will take to program something is famously difficult. So while I’ve been plunking away at my project for the last few months, I could see that I was still quite a ways away from anything I would be proud to release. And it’s not that I’m slow—well, I am slow, but that’s not the only reason—it’s that this project is very ambitious for a guy who’s doing this all in his spare time and teaching himself what he’s doing from scratch while he’s at it.
At this point I was starting to get a bit demoralized. I didn’t want to spend another year at this with nothing to show. Was there something quick I could whip up in the mean time? Basically a dry run to get something into the store. If I was going to make any mistakes, let’s do it on something that would only take a month or two, rather than 10 times that.
So I needed a new idea. I had a few criteria.
- Everything is self contained. Web service? Apple Watch app? One thing at a time please.
- Simple UI. Nothing’s coming from a web server, and no one wants to plug a ton of info into their phone.
- Useful. Frankly having a few dollars coming in would be a nice motivation to keep this going. It needs to be something I can charge at least $0.99 for.
- Not a game. I am not an artist, so interaction should be text based. That and I’m not really a gamer, so I don’t know what makes a good game.
So I talked it out with my girlfriend over some pizza. Erin suggested a budgeting app. That was useful, but it could easily violate number 1 and 2. Peoples budgeting systems get crazy complicated, and of course everyone’s going to want it to sync to… something. What about a lightweight budgeting app? After a week or so you’d realize this was completely inadequate. But what if you only needed it for a week or so?
Most people have some sort of budgeting system, from using elaborate spreadsheets to just roughly keeping it in their heads. But when you’re on vacation that all breaks down. Your routine goes out the window. You could use some way of making sure you’ve not blown all your cash by day two.
This was what I was looking for. An idea! One that seem feasible! Something to write about on my blog! Stay tuned.
Without A Map
Editors note: This will be nerdy
I haven’t written about iOS development in several months. I haven’t given up, I just hadn’t had much to say. I was still soaking it in.
I was reading two separate books, while occasionally going down rabbit holes to understand a topic a little better, and even watching some videos (specifically the much touted CS 193P). I even whipped up a few rough test apps just to prove to myself that I could get something running, even if it didn’t do much.
Then a little while ago I received an email from Apple saying it was time to renew my yearly developers membership. So I had been working on this for a year without much to show for it. So I decided I wanted to start something. Even if it’s terrible, even if I end up trashing it and starting from scratch later, this seems like a good time to take a first concrete steps.
That was my first impulsive decision. The second was, upon firing up Xcode, choosing Swift as the language for my new project.
Even though most of what I had learned so far had been Objective-C, which I have really enjoyed writing, I thought back to my initial feelings after WWDC last year. Swift was my chance to get in on the ground floor of something.
What made me confident enough to do this the fact that I now had a basic understanding of Objective-C. This is important because Cocoa makes a lot more sense if understand that it was created hand in hand with Objective C. You can still use the Cocoa APIs from Swift, but it still feels like there’s a layer of translation happening. You end up with some weird syntax and excessive casting that only makes sense when you understand that these APIs were designed for an entirely different language.
That said, what have I got to lose, at this point? This is the future, right? And WWDC made clear that Apple was still full speed ahead on Swift.
So I jumped in and started playing around. It had been a while since I read Apple’s The Swift Language, so there was a period of adjustment in getting used to the syntax. Swift is a very programmer-y language. It was built buy compiler guys, so “fast” was as important as “easy” or “intuitive”.
But after playing around for the last couple of months, I’m feeling comfortable with it. The pace of change has slowed down, and I’m finding myself able to work for longer and longer stretches without having to look up something basic. And Playgrounds have been really helpful. Sometimes you just can’t remember if arrays are passed by value or reference, but it’s easy enough to test in 10 lines of code on a Playground.
There have been stumbling blocks. I watched Apple’s session on Protocol Oriented Programming, and got so excited I went into my project and made all my model layers structs that conformed to a specific protocol. That did not work out so well, but that story is for another blog post (and if you want a more informed opinion, go back and read Brent Simmons’s Swift Diary). But in general when I sit down I make head way.
So I’m still working. In fact, I’ve got a couple ideas now. It’s all starting to feel manageable. Which, if experience tells me anything, means I’m only a couple of weeks from once again realizing I have no idea what I’m doing.
Choosing NSDictionary Keys
Say you’re creating a dictionary in Objective-C. The idea is that you have two objects that you want to link, where whenever you reference the one (a key), you get in return the other (the value). For example, you’re car shopping, and you’re writing a little app to help you pick which car you want. So you create some Car objects, and then go about classifying them. You pick some criteria, like “fastest car” and “most cup holders”, and you want each to reference the appropriate car. And you want all of these together, in one place, so that you can pass this dictionary around and make some kind of checks.
What do you use as the keys for this? NSDictionary has some pretty strict requirements as to what object can be a key, so most of the time the easiest option is an NSString. I guess you can just create some string literals, and use something like @“fastestCar” and @“mostCupHolders”. But that just looks… messy. You could initialize a string like NSString *fastestCar = [NSString stringWithString:@“fastestCar”] , but again, that seems like overkill. It would be nice if you could use an enum, but NSDictionary requires an object.
I noticed that for Apple’s use of imagePickerController, you’re passed a dictionary when the user choses photo. That dictionary contains the image itself, as well as some metadata. What was interesting to me was the keys seem were clearly objects, but really the type was arbitrary. All we were concerned with were the names, which were characteristically descriptive (e.g. UIImagePickerControllerOriginalImage).
Looking at the declaration, it appears that it’s defined as an NSString * const. Is there a string built in there? Not as far as I can tell. And it wouldn’t matter if there was.
The object, I learned cannot be nil, but it doesn’t have to actually be some arbitrary string either. Simply declaring NSString *const fastestCar = [[NSString alloc] init]; is enough. You’ve got an initialized NSString that makes a valid key.
Why bother? It’s not going to make a huge difference to your code’s readability, but it can lessens the cognitive burden of having to figure out a placeholder string, and it just looks cleaner than throwing string literals in there every time you want to access a value. It’s boilerplate, but it can be worth it if you’re going to be reusing this key more than a handful of times.
Objection Oriented Programming
A while ago, I saw a blog post from an experienced programmer lament that younger guys use Object Oriented Programming for everything because, well, that’s how they’re taught now. Often that makes sense, he explained, but sometimes you just want a quick script to do a task and be done with it. What the younger programmer could do in 20 lines of code this guy could do in 10 by getting rid of the object boilerplate.
I haven’t been doing this long enough to form any habits, but I do have some scripts that I’ve been using for a while at work. They mostly do one thing, They’re not pretty, but they work.
Then, I found myself wishing one of them did something else too. Or maybe instead of. Maybe I could add a small flag to change a behavior. That seems like it’s within my skill set.
Except, since it is just a 100 line procedural script, there’s really no way to break it out into base parts and change its behavior under certain circumstances. So I basically started tearing the script apart and putting it back together as a class, which I can then add methods to and call as I need. It’s not only that this will let me get my desired outcome today, but that this will make it (kinda) easier on me down the road, when I get further grandiose ideas.
The lesson here isn’t, I think, that one should always use OOP (or Functional Programming, if that’s your bag) for everything. The lesson is to think about the future, even with something small. If you’re writing a script that you expect to keep using down the road, try to future proof it as much as you can. Your needs will change over time, and that’s okay.
Nothing Was Delivered 