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.
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.
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.
Ooey-GUI
I saw someone on Reddit recently say that there are four stages to learning to program. I can’t find the link so I’m going from memory, but roughly, they are:
- The rush of excitement in learning something new – In this stage, you there are plenty of tutorials and hand holding.
- Venturing out – You are newly confident after having grasped the basic concepts. You can read (some) code and get an idea of what it means, and if you are not sure, you expect that you can look it up and figure it out. Sure, there are some areas of code that look impenetrable, but you are confident that you’re just missing a few more basic concepts and you’ll be able to understand them easily enough.
- The Wasteland – Now you want to do something non-trivial, and all the documentation still seems over your head. Everyone seems to know more than you do, and none of the tutorials are aimed at your level. They are either directed to newbies at stage 1, or they are directed to experienced programmers and assume that the reader has already worked with something similar, so they explain only what is unique about their implementation.
- Actually having some idea of what you’re doing – If you manage to somehow get pas the Wasteland, your confidence builds again, and one day you realize that you actually are able to build non-trivial systems.
I think the first three stages make a lot of sense. I’m not sure at this point if number four actually exists, or if it is just a cruel joke. I will say that there does seem to be a huge gap between the trivial (“Hello World!”) sort of programming and the more complex programming required to make what the average person on the street would recognize as software.
Modern software is complex. It does a lot, and everyone has expectations from years of using professionally created applications. This applies to mobile as well. It’s crazy to think that the iPhone launched 8 years ago. Everyone who’s been using a smart phone for even a fraction of that time has an idea of how an app on their preferred platform should look, act, and, more importantly, feel.
So what I’ve learned this week is that building GUI is really hard. Sure, you’re probably working with an SDK, so at least you’re not reinventing the wheel, but this is still hugely complex, with a lot of nuances. It’s hard to keep all of that in your brain at once.
Right now I’m working my way through the Big Nerd Ranch’s book on iOS Programming. They do a fairly good job of speaking in plain English–of helping you past the Wasteland. But it’s tough. I just finished the chapters on UITableView, a super common and relatively basic design. No bells and whistles here. Just a pretty standard list. And I’ve spent a good week trying to figure out a few challenges they give you. Move the items around the list. Create one item at the bottom that doesn’t move. You wouldn’t think this would be so hard. But because you’re not just dealing with variables and simple operations, but instead a whole mass of interconnected objects, things don’t behave the way they do in those first few tutorials. Intuition goes out the window. You’re basically left with trial and error.
Sometimes that’s good enough. And I get a feeling that more programming—real programming—is trial and error than anyone would ever admit. And through that method, I have almost completed the challenges. Now I have just one more simple method to master.
Mojo
The big question today on the tech blogs is has Apple lost it? You can rephrase that question several ways. Is Apple’s schedule of yearly iOS and OS X releases too ambitious? Are their priorities in the right place? Can any company reasonably expect to simultaneously grow platforms as complex as OS X and iOS and introduce a new watch platform while keeping software quality high?
I don’t know the answer to that. But I can tell you that I don’t see Apple slowing down any time soon.
Imagine a world where Apple held back several years between releases. We would all be using, what, Mountain Lion and iOS 6 today? Sure, it would be stable. But it would feel stagnant. Lacking of ideas. Your iPhone 6 would look antediluvian running a two year old OS, especially next to Android’s new Material design language. The “Apple bit off too much–is doomed!” argument would be replaced by “Apple is out of ideas–is doomed!”.
Apple are in a tough spot. On the mobile side, their competition is stronger than ever. Microsoft has stumbled on the desktop, but that doesn’t matter because the Mac is being measured against its younger siblings now. We expect our devices to work seamlessly together.
As a customer, I do think now would be a good time for a “Snow Leopard” type release. Fix the weird little bugs. But I don’t think Apple can get away with that. A year is a long time to tell the world that you’re busying working on bug fixes.
And frankly, while I do have complaints about the software I’m running today, I sure wouldn’t go back.
Learning By Doing
Several months ago I made two resolutions. One was to learn how to program, the other was to write about it more on this blog. I’ve partly kept one of those. The other, not so much.
Part of the reason is that I don’t feel that I had quite as much to say as I expected I would. I was reading some books and following along in some online communities, and that didn’t really sound interesting.
Now, though, I have a project. A personal itch that needs scratching. It’s small, and it’s pretty banal in the scheme of things, but it is kind of gnawing at my brain.
For my job, I find myself sorting large numbers of PDFs pretty often. The details aren’t important, but suffice it to say that this is something I’m sure a computer can do much more quickly than I can. So I set about figuring out how to get this done.
My first inclination was to come up with a Python script. I’m sure that it is possible in Python, but if I wanted to get into the raw data inside the PDF, I thought I’d need something more powerful. My next thought was to write something in C. This seemed like it would be way more effort than it was worth, since my knowledge of C is… well, lets just say I read a book on it once, and still own that book, so at least I have that.
My next thought was Swift, but again, there’s a serious learning curve there. Finally, I decided on Objective-C. Xcode offers an option for “Command Line Utilities”, so why not actually create one?
This is exciting because it’s my first time diving into an Objective-C project without a net. I honestly have no way of knowing how far above my head this project is until I hit a wall, and at that point there’s no flipping to the back of the book.
I started my project on Wednesday, after preparing for Thanksgiving. After working for a few hours here and there over the weekend, I currently have two classes totaling a couple hundred lines of code. I roughly sketched out the plan. The first goal was to find all of the PDFs in a directory. I got that part down. It took me a while, figuring out when to use NSArrays and when to use NSMutableArrays.
Beyond that rather basic syntax, my biggest confusion so far has been navigating the file system from inside an app. You have NSFileManager available to you, but some methods take NSURLs, and some take paths. How exactly do they work? Can I convert between the two? Are they really giving me what I want? How do I check?
I think I have that more or less sorted out. But now comes the hard part. Digging into a PDF file and seeing what I can pull out. I know the raw bytes I’m looking for are there. My worry now is separating the signal from the noise.
Nothing Was Delivered 
