I noticed this when experimenting with multiple tabs. When you set NSWindow.title to an empty String "", the window/tab will be hidden from the window list in the submenu below the “Window” main menu’s item. I expected a menu item with an empty label, but instead you get no item at all.
I found an interesting connection between two articles about paid up front apps, and how this paywall can work to your advantage in two ways by separating the ap user’s population into two groups, prospects and paying custoemrs: I never thought about the effect of paywalls on support email volume until Jordan Morgan launched his app Spend Stack the other day and now published an interesting argument pro paid up front pricing. Paid up front will limit your user base a lot compared to free-to-download/freemium, that’s true, but you’ll have a far lower volume of support emails, and you will only get emails from paying customers. Jordan receives 10–15 emails/day at 500 downloads/day right after launch. If you think freemium will increase downloads tenfold to 5000/day, he would also have to deal with hundreds of emails!
Found a question about how to “best” write the tests for the Fizz Buzz kata. The author provides his approach and questions as a GitHub Gist. One interesting takeaway is his use of the name of his constants, e.g. anyNumberDivisibleBy3 = 3. It expresses very well what kind of placeholder this number is supposed to be.
After the fiasco of sharing a single NSWindowController among multiple NSWindow instances, one per tab, let’s look at a proper implementation. For the working example, see the code on GitHub.
This is a follow-up to “Programmatically Add Tabs to NSWindows without NSDocument” from January this year. There, I was creating NSWindow instances from storyboards and re-used a single window controller to manage them. The point of that post was to solve the problem that newly created tabs will themselves not respond to the “+” button – or any menu action, for that matter, because they fell out of the responder chain at first.
I almost never forget to pack stuff for my regular trips to the gym, family visits, or shopping. Of course I sometimes do forget to pack something for a weekend trip, or I overpack books when I visit friends over the weekend and am afraid to run out of reading material during the train ride. But for the daily leaves of my appartment, I do not forget to pack keys, phone, money, writing utensils, sketchbook, etc.
I don’t know when was the last time I received a Microsoft Word .docx file. However long the streak may have been: it has been broken today. The document contained links and embedded images. I was instantly taken aback by the prospect of all the manual labor of extracting the images and saving them to files, not even knowing how MS Word behaves nowadays.
I compiled a crash reporter library with CocoaPods support. Check it out:
https://github.com/CleanCocoa/CrashReporter/
The past couple of days, I’ve been working on integration of an automatic crash reporter. Turns out that on some machines The Archive is crashing regularly during search, and I want to track this down. I need data by more than the most courageous users who can venture into the Console to track down crash report files and send them to me.
So I bit the bullet and began work on a server script that would accept crash report files and email them to me. I think that’s better than making users email me crash reports directly. Not everyone has Mail.app set up on her Mac, after all.
Fortunately, Brent Simmons open-sourced NetNewsWire 5 and blogged about his crash reporter. Brent has decades of experience on the Mac, so whenever he publishes a practical tip, I listen.
Just have a look at the code: Collecting .crash files and sending them over? Sounded simple enough! NetNewsWire even sports a very humble crash reporter UI, and automatically sending reports on the user’s behalf if the user choses to do so. The required Swift types are simple enough to integrate once you figure out where Brent put all the helper extensions :)
I cannot stress enough how amazing open source is. All this experience, assembled in publicly available code repositories for everyone to grab and use. This is crazy.
I am now rolling this out for my apps, starting with the WordCounter and The Archive on their respective “beta” update branches to see how it works in practice. The Swift code is simple and I trust it doing its job. But the server script, well, it needs to be battle-tested now!
I’m going to add public-key encryption of messages and/or some sort of authentication to prevent malicious attackers from spamming me with emails that, well … I send to myself.
I just released an update to Move!, the work break app I develop and use. It fixes a couple of user experience issues, like displaying a Dock icon when you view the preferences so you don’t lose the window.
Also, the app’s preferences didn’t display license details properly on Mojave and above. The app now uses Swift 5 and updated external libraries under the hood, is properly notarized (hello, Catalina!) – and a couple of MiB larger than before. I am looking forward to when we can depend on the Swift runtime being available on user devices.
I manually edited about 400 occurences of code block markers from #!swift into \“swift`. I hope I didn’t break anything in the process. So far, things look good. If you find oddly looking posts or broken code blocks, please tell me about them. There’s no way I can find problems on my own in 10 years worth of blog posts :)
This time, I don’t want to find out if the app is compiled as debug/release mode; I want to find out if the debugger is attached. I found an Objective-C answer on StackOverflow which is based on HockeyApp-iOS.