After watching the Keynote, I was thoroughly impressed. While there still isn’t a dark mode for iOS, I can imagine it coming soon. And there are a lot of cool things that were announced.
While watching the event, I took a note of the top 4 for each OS, excluding tvOS, because who cares?
So here they are:
- Siri Shortcuts
- Screen Time
- Automatic Workout Detection
- Walkie Talkie
- Interactive Notifications
- Dark Mode
- Dynamic Desktop
- Mac App Store
I plan on doing some writing about the new features, but in more of an opinionated way, rather than a simple informative guide. You’ll find these with the WWDC 18 tag.
Tim Hardwick, writing for Mac Rumors:
Stationery Pad is a handy way to nix a step in your workflow if you regularly use document templates on your Mac. The long-standing Finder feature essentially tells a file’s parent application to open a copy of it by default, ensuring that the original file remains unedited.
Stationery Pad doesn’t get much attention these days, but it’s a neat alternative to repeatedly editing templates and using the “Save As…” command, which can lead to overwriting the original file if you’re not too careful.
I had no idea this existed. I will most certainly be making use of it in the future.
Say you write an iOS app, and now you want to write the Mac version.
Assuming there’s a data model, maybe a database, some networking code, that kind of thing, then you can use that exact same code in your Mac app, quite likely without any changes whatsoever.
I agree with Brent here. I’ve never really understood the argument that AppKit is that difficult to understand, so that’s why people don’t port native apps over. Surely the underlying logic of the app is the hard part, and linking the functionality to the interface is the easier part?
I would say I’m more of an iOS developer, simply because I’ve spent more time on it. But I’ve also made a few Mac applications. Sure, a resizing window is a bit more complex than a relatively fixed screen size, and some the interface elements are names slightly differently.
It’s just different, for both sets of people. But not as difficult as it may seem.
In a recent article by Mark Gurman over at Bloomberg, he wrote over 600 words on the supposed plan that Apple have, which would converge apps from iOS and macOS. Meaning that developers would be able to design just one app, and have it work on both platforms.
I personally dont think this is going to happen.
And if you read the whole piece, you’ll find that only 48 words out of the total 672 are relevant:
Apple currently plans to begin rolling out the change as part of next fall’s major iOS and macOS updates, said the people, who requested anonymity to discuss an internal matter. The secret project, codenamed “Marzipan,” is one of the tentpole additions for next year’s Apple software road map.
I’ve been hearing Mark’s name for a few years, and people always seem to make him sound like a very top Apple reporter, which I guess is why he now writes for Bloomberg. But his latest rumours, have been a bit lower in quality in my opinion.
Read the “full” article on Bloomberg.
Here’s something interesting – The guys over at iA (devleopers of the iA Writer app), have made their own font. Prevously the apps used a font called Nitti, which kind of became part of the iA brand, but they took it upon themselves to develop a more writing focussed option.
Hell just froze over. After seven years of offering no font options to write, iA Writer now comes with a choice. Next to the monospace Nitti you will now find a brand new duospace font. Duospace?
For an app that was designed as the digital equivalent of a typewriter, a monospace font is not a far fetch. But, if font choice were just a matter of style, there are better and less expensive ways to impress than leasing a high end monospaced typeface that many take for a silly Courier.
There was clearly a lot of investigastion that went into it, and I’m a fan of the results!
Read the full article on the iA Blog, and download iA Writer for iOS and macOS.
I finally got around to checking out the code for one of my apps, Qwiki.
Qwiki is a menu bar application, that lets you search and read Wikipedia articles. It can also open them in the browser, share differently formatted links, etc. But this isn’t an advertisement.
After updating it to 1.3 last year, I had other projects, university, and finding a job to do. So it got pushed right to the side. But I decided recently I wanted to modernise it, and maybe even look at adding new features.
That time hasn’t come yet, but I have spent the past few days going over the code, cleaning a few things up, migrating it to Swift 4, etc.
So in the mean time I fixed a couple of bugs, like when keyboard and mouse input get mixed up, escape key not always working, some design tweaks, and also added a preference to keep Qwiki open unless manually dismissed.
Now it’s been sent to Apple, I’ll have a few days off, and probably work updating another one of my apps. But in the very near future I plan on going back to Qwiki, and seeing what real features I can add!
If you have any ideas at all about Qwiki, then i’d be really happy to heat them. Even if it’s pure criticism, it all helps.
Check out the Qwiki website, or find it on the Mac App Store.
Jannis Hermanns took on a rather interesting challenge recently, and it was all about working from an iPad Pro.
But unlike most people that make the switch, he’s not a writer, manager, or a designer. Jannis is a backend engineer, that uses some terminal in some hardcore ways!
In the summer of 2017, I wanted to know what it would be like to use an iPad Pro as my main computer. I found out that it can actually work, thanks to an iOS app called Blink, an SSH replacement called Mosh, iOS 11 and running stuff on a server.
His perspective/experience I find, is different than most other macOS to iOS switching articles, as there was a lot more technical issues that had to be solved.
But nonetheless, he managed it in the end.
Sadly for myself though, this switch isn’t something that I could do myself any time soon, as I develop 99% of the time using Xcode. Sure, I could probably run that on a Mac, and use a iPad to operate it. But what’s the point in that.
Read the full post.
I’ve been wanting (not exactly looking for) a better way to quickly deal with screenshots on macOS for a while, and while looking over Product Hunt today, there was an app called ShotBox climbing the ranks.
It was free, and it looked interesting, so I gave it a shot. I was very pleased with what I found, and it’s such a simple utility, but it’s exactly what I need.
It’s similar to the new screenshot feature in iOS, in that when it detects a new screenshot, it opens up a small window in the bottom-left corner, so you can quickly edit and share.
There are actually only two things you can do in that window, and they are preview and edit. And of course when you close the window, you get the option to quickly delete the screenshot, or to save it.
I initially didn’t think it would work properly on my Mac, as I have Hazel move my screenshots into a separate folder, which I then have rules on archiving. So therefore they don’t just sit on my desktop. However, ShotBox lets you select a folder to watch, so this wasn’t an issue!
You can find out more information on ShotBox, and also download it for free using these links:
Michael Rockwell, over at Initial Charge write a piece about a really interesting way to give web apps a more native feel on iOS.
Firstly, he mentions Fluid, which is an application for macOS which lets you “convert” web apps into containers that run as normal apps:
On macOS, there’s an application available called Fluid, which lets you create site-specific web browsers. Many of us use web apps everyday and Fluid allows you to run them side-by-side with your native applications without being sequestered inside of a web browser. Fluid is a handy little tool that every Mac user should have in their arsenal.
I hadn’t heard of Fluid before, so I’m going to try this myself, but it’s not as good as his next suggestion for iOS:
To build these site-specific browsers, it just takes two simple actions — a URL action with the web app’s address and the Show Web Page action. When run, Workflow will open up the URL in a Safari View Controller, which gives you access to your action extensions alongside forward, back, and refresh buttons. From there you can give the workflow a name, set an icon color, and a glyph to fit the website or web application’s functionality.
So, he uses Workflow! It’s something I haven’t thought at all about before, but it makes sense. You can use the standard Safari View Controller inside Workflow, or you make partner it with apps like Sidefari, or maybe even add another layer to it with Opener.
I’ve actually just set one up myself to handle my the interface for this blog, which runs on Ghost.
Whether you use macOS or iOS, there’s a solution for you in this post!
Stephen Hackett (with help from the Relay FM designer – @forgottentowel), has created a page containing every default macOS wallpaper in 5K!
I’ve downloaded a few myself of course.