If you are preparing to install macOS on multiple computers, one of the things that can make your life simpler (and the waiting shorter) is a bootable USB installer.
The idea of the installer is that you only need to download the macOS Installer.app from the App Store once. Usually, when you run the installer after downloading it, it’ll delete itself and you have to go through the whole download process again on each machine or disk that you want to install macOS onto. By making a bootable USB drive, you simply plug the drive in to your mac, launch the installer app and tell it where to install the OS. You can repeat this as many times as you like as the installer will remain safe on your USB.
There are various ways to make a bootable USB installer, but they all involve the same process:
1. Download the macOS Installer from the App Store.
2. Run the
createinstallmedia command from the Terminal, an AppleScript or a helper app.
3. Reboot your mac, choosing the newly created USB as the startup disk.
4. Run the installer.app from the USB.
Step 2 is where the fun is. The
createinstallmedia command can be tricky to get right, particularly if you’re not familiar with working on the command line. For those of you that are, follow Apple’s instructions here.
For a little more convenience, I wrapped all that inside an AppleScript which will first ask you for the location of the installer, then ask you to choose the USB target.
For maximum convenience, I also wrote a free little Swift app I’ve dubbed ‘Boot Buddy‘ (cos “Create bootable macOS Installer Drive.app” just didn’t quite have the right ring to it..!) that will present the whole thing in a neat little user interface. Three clicks, more or less, and you’re done.
Boot Buddy doesn’t require an admin password to install, but you do need to provide an admin password to actually create the bootable installer as the
createinstallmedia process has to be run as root. Boot Buddy doesn’t see or use this in any way whatsoever other than to start the
createinstallmedia process or to cancel it (if you choose to do so); authorisation is handed off to macOS to take care of.
Boot Buddy requires macOS 10.11 or higher and can create bootable USBs from Mavericks, Yosemite, El Capitan, Sierra and High Sierra installer apps.
Share and enjoy! 🙂
With malware big in the news again, and evidence that at least one malware variant that targets macOS creates hidden users on the victim’s system, here’s a timely tip on how to check for unwelcome guests.
For this tip, we’re going to use the Terminal, which you can find in the /Applications/Utilities folder. If you’re not a frequent visitor to the land of the command line, you might want to see my 3-part series “Learning the Terminal”.
Regardless, the first thing we’re going to do in Terminal is about the simplest command you’ll ever type:
w. Yep, type a single ‘w’ at the prompt and press return.
w utility is a very quick way to see who’s currently logged on to your system and to ensure that there’s no surprises. You should see a couple of entries for yourself: one as ‘console’ and one as ‘s***’. The first represents a login through the usual Desktop GUI login window; the second is there because you just logged into Terminal. Anybody else logged in either via the command line (like a potential remote user) or the GUI will show up here. Notice that on my machine, there’s another user called ‘Developer’ who hasn’t logged in using the GUI, but is logged in via a command line interface. Note that ‘w’ returns the full user name, not the short one.
w utility will tell you if a hidden user is currently logged on, what if there’s a hidden user that isn’t active at the particular time you check? To look for those, we have a couple of options. First, we can use the
dscl utility to list all users, and you might be surprised at how many there are:
dscl . -list /Users
Look to the end of that list where the names that don’t begin with an underscore start. ‘Daemon’, ‘Nobody’, ‘Root’ and ‘Guest’ are all standard system accounts, as are all those entries that begin with an underscore. Don’t worry about those. However, aside from those, you should only see names that you recognise. To make things a little easier, we can add another command to the dscl command to filter that list. Try this
dscl . -list /Users | grep -vE ‘_|root|nobody|daemon|Guest’
That should now only return the names of real users. There shouldn’t be any names in there you don’t recognise. In my example, I know the last three, but the first one ‘dev’ isn’t familiar to me. Note that unlike ‘w’, this command returns short user names, and that ‘dev’ looks very much like it’s the same account as ‘Developer’ that I saw earlier.
However, what we have so far is a list of users, not a list of hidden users. To see specifically if any accounts are hidden, we need a longer command:
defaults read /Library/Preferences/com.apple.loginwindow
Normally, when there are no hidden users, this will return the contents of a property list file that may look something like this:
GuestEnabled = 1;
OptimizerLastRunForBuild = 31898816;
OptimizerLastRunForSystem = 168494592;
SHOWFULLNAME = 1;
lastUser = loggedIn;
lastUserName = imackim;
That tells us that there’s no hidden users on this mac. How so? Because if there were it would return something very different, like this:
We can see not only the list of hidden users, but also that the preference for hiding users has been set to ‘1’ (in plist syntax, ‘1’ means true and ‘0’ means false). Note again that unlike the
dscl command above, this returns the account’s full name, not the short user name.
If we’d like to ‘unhide’ that user, so the account appears in the login window GUI and in System Preferences’ ‘Users & Groups’ pane, we’ll need admin privileges. To do that, cut and paste the following into Terminal:
sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool NO
Supply an admin user password at the prompt and hit ‘return’, but type slowly as the display doesn’t register your key presses, which makes it easy to fat finger your password.
Next, we need to change the
IsHidden key in
dscl for that user, so
sudo dscl . -change /Users/dev IsHidden 1 0
In the above command, substitute my user’s shortname
dev for the shortname of the user on your machine. The
1 0 is the old value (hidden) followed by the new value (unhidden). The line can be read as “change User dev’s IsHidden value from hidden to unhidden.”
For the more advanced
We can save ourselves some typing by putting much of this into a script so that we can run it whenever we want. If you’re not familiar with how to create and use bash scripts, take a look here.
Our script will basically do the same as all the commands we listed above (except changing the prefs for
Hide500Users) in one fell swoop, and there’s a couple of little twists that I’ll leave as an exercise for the reader to figure out. To save on the typing, you can copy the whole script from my pastebin here.
The script’s output is illustrated in the shot at the top of this post.
This little tool will help you keep track of when Apple make changes to system config data like XProtect, Gatekeeper and the Malware Removal Tool. It will also alert you if there is a Security update in the App Store that needs to be manually applied.
Critical Updates is free for home use. Organisations wishing to license it for commercial-scale use should contact me through Sqwarq support.
With macOS 10.12 Sierra due out sometime this month, some will no doubt be wondering whether their current mac will make the cut.
First thing you’ll need to know is your model identifier. If you’re using DetectX or FastTasks 2, it’s displayed at the top of the Profile log. In FastTasks 2, you can also find it in the menu under ‘Model Overview’.
If you’re not using either of those, you can get your model identifier from > About This Mac > System Report… Look for ‘Model Identifier’ under the Hardware Overview section.
Barring any unlikely last minute changes from Apple, here’s the full list of models that are supported:
For those participating in Apple’s public beta program or developer program, here’s a script that will make a bootable flash drive installer of Sierra for you. Of course, you’ll need to have downloaded and saved the original installer before running it on your mac for this to work.
When an installer is made available to you from Apple, the first thing to do after downloading it is to quit the installer if it auto runs. Insert your blank USB thumb drive, and make sure it’s at least 8GB (16GB recommended).
You can either run the script immediately with the installer app still in your /Applications or /Downloads folder, or you can move the installer first to your preferred location. It doesn’t make any difference to the script since it’ll ask you for the location of both the Installer and the USB drive before doing its thing. It’ll also give you an option to cancel out if you made any mistake in specifying the location or you just change your mind. The script will ask you for an administrator password as it needs elevated privileges to run the
Note the script continues to run in the background until the installer has been created. It sleeps for an interval of 10 secs between checking the job status. Since it takes around ten minutes for the createInstallMedia routine to finish its work, you could comfortably increase that sleep time 30 secs or more if you desire. The script will present you a dialog when it detects all is done:
To use the bootable installer, just pop it into a mac, reboot holding down the ‘option’ key and choose the USB drive to kick off the installation process on a partition of your choice.
Developing apps for iPhone, iPod, iPad, and Mac OS seems like the California gold-rush of the 21st century — the press are full of reports of the riches to be had in this amazing land, stories of “little people” making “big bucks”. Anyone can be an app developer, they say, but what’s the truth behind the hype, and how do you actually learn how to do it?
Last I heard, there were currently something like 600,000 apps on the Apple App store (for iPhone/iPad) and some 100,000 or so on the App store for Mac OS. Apple have paid out (i.e., passed on customer payments after taking their 30% cut) literally billions of dollars to developers. That’s a lot of cash! The question is, can you get a slice of it too?
In theory, there’s no reason why not. As I’ll detail below, the route to becoming an app developer is not particularly hard, nor is it particularly costly. But that doesn’t guarantee success. Anyone can write a book, but writing a killer book that’ll sell like Harry Potter is not so easy, and writing a killer app that will sell like Angry Birds is every bit as difficult.
The analogy holds for success in both cases: you need a great idea, you need to execute it well, and you need to market it properly. Did I mention those 600,000 apps on the App store? How, exactly, are you going to make your fortune if your app is buried in a pile like that? Well, I’ll save ideas and marketing for a future post. In this one, I want to focus on the things that we know we can achieve and only have to depend on ourselves for: developing the skills needed to turn that great idea into an actual piece of software that will run on Apple machines.
Learn the language
If you want to write a killer novel, the first thing you have to do is learn the language that you want to write the novel in, be it French, Chinese, or English. If you want to write a killer app, the same goes. Visual Basic? Visual C++? Java? Yes, that kind of thing except…if you’re developing for iOS (the iPhone/iPad operating system) or Mac OS (Mac computer operating system) you have to learn the Apple language, not any of those common ones associated with lesser machines!
So what is the Apple language? It’s called ‘Objective-C’, and it runs in a programming environment called ‘Cocoa’. You’ll need to learn ‘Cocoa’, but in order to learn that you’ll need to learn ‘Objective-C’, and to learn that, you’ll need to learn the basics of the standard (Ansi) C programming language. Oh my!
And once you’ve got a hold on all that, you’ll then need to learn Xcode, which isn’t a language or a programming environment at all, but a very sophisticated development tool (in fact, Xcode is itself an app!), in which you do all your Apple programming. You’re probably now thinking that it’d be easier to write that next Harry Potter novel and are already hunting around for the back of an envelope to start scratching down your ideas, but wait…
I know it sounds disheartening, but there is some good news. After all, it can’t be that hard if so many other people are doing it, right? (Well, actually, yeah it can, there’s a lot of dedicated programming geeks out there!). But look, I’ve been down this road too, and while I haven’t produced any killer apps (still waiting for that great idea…), I have gone from knowing next to nothing about programming to being able to put together an application that does what I tell it to and doesn’t crash my system.
(OK, not entirely true that I didn’t know anything about programming: in the 1980s, I once learned how to get a monochrome computer screen to print “Hello World” in BBC BASIC, which basically involved nothing other than typing >Print “Hello World”; it seemed so ridiculously pointless in 1982 that it turned me off programming for the next thirty years! Other than that, I’m a newbie 🙂 ).
And the good news gets better: most all of the documentation you need to learn how to be an app developer is available free from Apple. Truly, and I mean this with no trace of irony, it is hugely generous of Apple to put the amount of free material they have online for anyone to use. Want to be a Windows developer? Find your local bookstore and start shelling out one heck of a lot of $$$!! The cynical, of course, will say that Apple only do the giveaway to benefit themselves; others might say that giving away free training justifies their 30% cut.
I think of it as a symbiotic relationship: would-be developers who aren’t in computer science departments or big companies could never afford to buy all the material. Likewise, Apple could never have built an App store with such a huge number and wide variety of programs to Wow! their users if they had only had universities and commercial software developers to rely on. This way, both the little people, that’s me (and — I’m assuming — you), and Apple get to win.
I’ll tell you how to get started in a minute, but before I do let me point out that the ride is not entirely free. There’s probably a point at the beginning and certainly one at the end where you will need to lay out some of your hard-earned. So let’s deal with that now.
What you need
Right off, you’re going to need a Mac computer. Sorry, if you don’t already have one, you’re going to have to buy one; a low-range Macbook Air or Mac Mini will do, anything that can run OS X Lion. You can’t develop Mac apps on your iPhone or iPad, I’m afraid (but it does work the other way too: you don’t need an iPad or iPhone to develop apps for these devices. More on this below).
And what about if you have a good-spec PC? Yes, you could get a Mac emulator (VMmare) or mess around with OSx86, but frankly, these options are likely to cause you more grief than they’re worth; you could end up with apps that don’t build properly, and/or which breach Apple’s licensing conditions.
I’m not saying don’t do it, that’s your choice; I am saying your chances of successfully building an app, making it stable, and getting it accepted into the App store by Apple are significantly reduced if you go that route. Given the price of a basic Mac Mini on Ebay, you could well end up spending more money (as well as time) trying to avoid buying a Mac than just buying a cheap one.
The other expense you might need to lay out for is a basic ‘Intro to C’ book. There’s plenty of web offerings, but really a good ‘idiots’ book like the Dummies or Absolute Beginners should be enough and has the benefit of being reasonably likely to get you to the level of proficiency you need in the shortest amount of time. After that, you learn the rest for free (Objective-C, Cocoa, Xcode) from Apple. At the end of the process, when your app is built and you want to submit your app to the App store, you’ll have to register with Apple for a licence as an app developer and vendor; current cost $99.
Take the first step
“Sign me up”, you say, “where do I start?” The first thing to do is to sign up to Apple’s developer community: this is free (don’t confuse it with the Developer Program or Licensing, which costs $99 and which you don’t need till you’ve built an app you want to upload to the App store).
Once you’re in the Developer Community, download Xcode 4, Apple’s development environment (a different thing from a programming environment, but don’t worry, you’ll get the hang of all this terminology easily enough once you start reading the docs). This is a 4GB monster of a program – bigger than your average operating system, so make sure you have the space – and it is also free. Xcode comes with free iPhone and iPad simulators and in itself, this is a piece of software that’s probably worth a couple of thousand dollars. So smile: you’re already making a profit even though you bought that Mac Mini! This is also the reason why you don’t need, and in fact can’t use, your own iPad or iPhone to test your apps: everything has to be done in Xcode, and this monster app only runs on Mac OS X.
Once you’ve downloaded Xcode, you can play around with it if you want, but unless you’ve worked with an IDE (integrated development environment) before, it’s pretty complicated, so it’s best to wait till you work through the tutorials. It’s not the kind of software you can learn through serendipitous exploration.
Instead, go to the documentation resources and start with the tutorial Your First Mac Application.
By the time you get through this, you’re going to realise why you need to learn Ansi C, Objective-C and Cocoa. So put Xcode away for now, and start on the path of learning to speak Apple’s language. When you get there, just add 1 great idea + 1 great marketing strategy, and you’re on your way to California!
The short guide:
1. Get a Mac
2. Learn C, learn Objective-C, learn Cocoa, learn Xcode
3. Come up with an idea for a great app and plan it out carefully
4. Build and test your app
5. Pay the licensing fee and submit your app to Apple
6. Once it’s been through the review process and accepted, implement your marketing strategy
7. Watch the millions role in and retire.
It’s been over 10 days since the jury went out to weigh up the evidence for and against Mac’s new operating system, 10.7 (OS X Lion). With Apple announcing a million downloads in the first 24 hours, there’s been no shortage of heated debate across the blogosphere and discussion boards (this thread runs to 60 pages and counting! Also see this witty and perceptive post about one user’s frustrations with the upgrade).
So it appears that some love it, others hate it, many are merely sanguine about the whole experience. A number of people are reporting trying it and reverting back to Snow Leopard with brow-mopping relief. My guess, though, is that the vast majority of Snow Leopard users are patiently waiting till a few updates have been released and all the early bugs ironed out.
It’s worth remembering the options: even if you buy Lion now to take advantage of the $30 opening price, you don’t have to install it now. You could buy it and leave the installer app in your Apps folder till the updates get released. Nor do you have to install it over the top of your existing installation. You could install Lion on an external disc instead, or move your Snow Leopard to an external disc and have Lion on your internal disc. Either of those options will allow you to play around with it and switch over fully when you’re truly ready. Don’t forget you can check out whether your existing software will work with Lion.
I have to say though, after ten days, 10.7 is starting to grow on me, and I think the external drive with Snow Leopard sitting on it is going to be gathering dust in a cupboard from now on. That’s not to say I’m thrilled with all that Lion has to offer. It’s a mixed bag, so sit back and let me read the court’s judgement in full. 🙂
The Good, …
— yes, I have unwillingly been converted. The four-finger screen swipe (left/right to change screen, up/down for Spaces and Expose, respectively) is addictive, and now I don’t think I could live without it. The truth is I could never get along with Spaces or Expose in Snow Leopard anyway, but Mission Control really does sort of force itself upon you. I do miss the App Switcher that is no longer available via the trackpad (Cmd-Tab still invokes it). There are free 3rd Party programs that you can get to add it back into the trackpad, but my experience is they are awkward at best.
— this is an app I use a lot and I love what they’ve done to it. Preview’s enhancements are one of the most undersold changes in all the talk about Lion. It’s always been ahead of Adobe Reader to my mind, but it did have shortcomings, particularly with adding and placing comments neatly and readably. The new Preview has tidied that up nicely, with the comment markers placeable with much finer precision and clear, neat lines indicating which comment each belongs to. The full screen feature also looks great and makes reading a pleasure.
— is growing on me. Switch it back to Classic view for a tidier interface, but there’s still lots of nice things about it. The animated display when you double-click to open a message is very neat (note: you won’t see the animation if you’ve got your IMAP account settings set to ‘Don’t keep copies of any messages’ in Mail Preferences | Advanced).
the Bad, …
Well, overall, the worst thing about Lion is that most of the good things are really cosmetic. There’s not a lot of new things you can do with Lion, and what there are, I don’t like much, particularly the triumvirate of data guardians otherwise known as
Resume, Autosave and Versions
— Apple has gone to extraordinary lengths to ensure every keystroke, every page, every file you ever open is remembered somewhere (and often in multiple somewheres) on your internal drive and your backup drives. It’s worth noting that not all of these are places the average user can either find or remove. This is something that not everyone is thrilled about, and certainly it’s raised a few eyebrows among the security-conscious. If I were a Chinese blogger, I’m not sure I’d want to update to Lion (you think the Chinese don’t buy Macs? Oh,please!). Another thing worth noting about the Evil Trinity is that Apple has also made them extremely difficult to turn off. Resume, despite what you might be reading elsewhere, cannot be turned off by default (or at least no one’s found a way to do it yet).
However, with all these things, it’s not so much that you can’t beat them, but that you have to work around them. Adjusting your workflow to avoid Resume, Autosave and Versions is certainly possible, but something some may rightly begrudge paying $30 to have to do (in which case, that external backup of Snow Leopard I mentioned above is your friend!). I’ve already written about Resume, and I hope to post workarounds for Versions and Autosave in the near future (sign up for the RSS feed).
The only other ‘bad’ thing I have to say about 10.7 is LaunchPad. This is the iPad look-alike-finger-swiping app display (known as ‘springboard’ on the iPad). A complete waste of time: literally, it’ll take you forever to organise it, and even then it’s a very slow way to find anything but your most familiar apps. There have always been much faster and more efficient ways to get to both your most-oft used apps (the Dock) and those you only occasionally fire up (Finder).
…and the Ugly.
It’s not often that Apple do ugly, but its been universally acknowledged that the designs for iCal, Address Book and Photo Booth are a real eyesore. Fortunately, it’s easy to get rid of them with a bit of mucking about.
So should you upgrade or not? Well, why make it a black-and-white decision when you could have the best of both worlds? If you have a spare drive hanging around, whip it out, pay your $30 and take Lion for a test-drive. If it’s not for you right now, just put it away till the updates smooth it out and the time is right regarding compatibility. After all, if you’ve invested heavily in Apple products or have a lot of legacy material, then it’s probably only a matter of time before you give in and let the Lion tame you, too!