Working on a greenfield project is nice, but it also brings up all the uncertainties of the start: which components, modules, objects, interfaces do you need? With Swift, you even have to decide if you want to design the system in an object-oriented or a functional way. As far as the core functionality is concerned, you do have this choice. (When it comes to UIKit/AppKit, you don’t.)
With some luck, all my Windows programming wet dream might actually come true one day. There’s progress on making Swift available on Windows, and there’s progress on providing a Win32 API wrapper for Swift so you can share model code across platforms and write UI for Windows and Mac separately.
Check out the GitHub repo: https://github.com/compnerd/swift-win32
It’s experimental, but apparently way less experimental than it was a year ago!
Berlin-based company ExactCODE, makers of ExactScan and OCRKit, experiences trouble with Catalina and a rather short time to submit bug fixes for their app before the public release of Catalina earlier this month. They decided to leave the Mac App Store behind:
- each manual update review by Apple causes delay and drama
- AppStore does not support paid upgrades, only new App, in-App purchase or subscriptions
- Apple takes 30% and that is not sustainable to run a company and pay salleries
- it is not provide to provide free updates forever
- if you purchased our application this year we provide a direct license, if you had it significantly longer, we think a paid upgrade is fair for continuously developing, improvements, and support
[…]
There is mostly only one benefit [of using the MAS] for users: one central place for purchasee and updates. However, there are many negatives, such as: […]
I don’t know if they could’ve done more to prepare for the macOS upgrade. Recently, folks on Slack shared screenshots, and it turns out that as a serious Mac developer you apparently have external hard drives full of previous and future macOS versions, plus a stack of different Xcode versions (that are no longer available for download by Apple!) – that’s required by virtually everyone in order to support multiple OS versions and fix bugs. The Catalina beta also was very flaky.
After releasing the Catalina Golden Master build to developers on October the 3rd, we immediately finished fixing any new crash or issue we could find over the weekend. In our opinion, leaving developer just four (4!) days over a weekend with a public release on October the 7th is not very helpful nor professional.
They have a point here. But could they have fixed the same bugs earlier in preparation of the Golden Master release?
The call for App Store submissions went live on October 3rd, too, at the day of the Golden Master release. So even if they fixed all the bugs early, Apple would have had only 4 days to review all App Store submissions, which sounds like a bad idea nevertheless.
See also:
Shameless plug: I also wrote a book on selling outside the Mac App Store in case you want to leave the App Store, too, or make your company more resilient through availability in multiple stores.
After a couple weeks of experimentation, I find that twice weekly email delivery of my recent blog posts is one too many. I wrote a lot in the past months, so each issue contained quite a few links. But who wants more email with less links in it? I don’t, so I changed the interval to weekly, delivered every Thursday, covering a summary of the whole past week.
As an exercise, I wrote a simple iOS scene transition from a login form (root view controller) to a success scene. I was experimenting with the Model-View-Presenter approach where view and presenter know each other, but communicate through protocols, so you program to an interface, not the implementation. I ended up using a simple state machine to represent the view’s state, and employed form validation that is represented in the types. I like how the result reads, so here’s a rundown of the exercise:
What I called an Xcode bug last week turned out to be a broken project configuration that was absolutely my fault. Back when Hardened Runtime was introduced, I switched it on at the Xcode project level, not just for the app target. When you set “Enable Hardened Runtime” on the project level, all targets inherit this setting: the app, the unit tests, and the UI tests. With Xcode 11, it now turns out that hardening the runtime for the test runner broke an internal library lookup in perfect accordance with the utility of the Hardened Runtime settings.
Rich Siegel recently wondered on Slack why NSTextView would suddenly display empty placeholders for some glyphs when the font does not support them, instead of falling back to a safe font like it usually does. Chinese characters never got displayed. Michel Fortin remembered a similar problem, and the potential fix was quite simple:
In summary, if you have to change the font after the text storage was edited, do it in
willProcessEditingand it’ll do the right thing. Don’t do it indidProcessEditing.
That turned out to be what tripped up Mr Siegel’s text view, which now happily displays CJK/CJKV again. For more details and some background about how you can detect this problem in your apps, read Michel’s post.
I’m currently revising code from 3 years ago. The result is a replica of the old stuff – updating isn’t worth the effort, it’s written in Swift 3 and the code base is small, so I rewrite it and copy useful parts over. The public interface already differs from what I wrote 3 years ago. In the first step, I translated the old code but took what was there. For example, back then I had a DateRange type. Swift Ranges were less powerful back then, so I added a couple of convenient methods that I can now replace with the standard library protocols instead. So I demoted the type to typealias DateRange = Range<Date>. I also had a Date type (this was before NSDate dropped the “NS”) that I renamed to NormalizedDate. In the domain I work on, a date isn’t a date-time-combination, but just the year, month, and day. Confusingly, this type was a mere wrapper for NSDate that dropped the time information for quick comparisons.
By accident I found a setting for emacs windows that prevents a window from displaying any other content than what it currently is showing. It is not locking the textual contents but the buffer. That means you cannot show the contents of another file, or change the currently visible help page, or whatever.
Emacs can display interactive help windows (the content/buffer name is called “*Apropos*”), and compilation results. I managed to limit the height of the compilation window to 10 lines already. But when I have the compilation results pane focused, I want to close and dismiss it quickly.
The project that I’ve been working on over the weekend, I worked on in emacs. This is part of my re-learning the basics of text editing and programming in emacs to slowly move away from TextMate when it comes to scripts. I want to move away from TextMate because I eventually want to transition to be productive on a Linux machine – that means, to create stuff in an otherwise foreign operating system. Emacs is portable, so that’s a good start.
This announcement is a very difficult one: I cannot work on The Archive for the next week or two, maybe, more. That’s because with Xcode 11 and Swift 5.1, UI Tests stopped to work. Like, at all. I have created a Feedback ticket (FB7338237) and now also have a Technical Support incident open, awaiting a reply by Apple engineers to help with this.
I was experimenting with PHP development over the weekend to whip up a properly unit-tested library to generate license codes, hosted on your own web server. I wanted to make use of my newfound emacs prowess and figure out how programming is supposed to work with the stuff I have and have not prepared so far.
Since macOS 10.15 Catalina, you cannot easily make public logging the default anymore. os_log hides contents from string interpolation by replacing the string with <private>, unless you explicitly annotate the value with %{public}. That’s probably supposed to force developers to think which parts absolutely need to be part of the log and thus reduce accidental logging of private information. Saagar Jha shows how you can enable your dev machine to log everything again.
For all throughout human history, you had to symbolicate your user’s crash logs using atos or a 3rd party tool to get human-readable output. Otherwise, you will not know the symbol or method name of your app’s parts that are involved and see memory offsets instead. But with Xcode 11, double-clicking a .crash file now opens Xcode instead of Console, and you can view the crash log in the context of a project. That’s very nice.
I uploaded another episode of the video series where I document how someone might process reading notes from a book after reading it. I don’t have any Range related project, so here I’m just processing the book from start to finish instead of looking for anything in particular.
This episode is shorter, because I didn’t find many useful ideas in Chapter 3. And the ideas I did find interesting were not citable, so I had to look the originals up. That took most of the time, but did ultimately not produce many new notes. It’s interesting that after a couple of session I already begin to form an opinion of the quality of Epstein’s research. There’s lots of endnotes, but the quality is … well, enjoy this episode to find out more!
Episode list:
I’ve just published an overhaul to the website that affects all the CSS. I do hope the typography looks better in general. Also, I’ve revamped the books and apps pages to look nicer, have more detail, and make purchases easier.
The large update and rewrite of “Make Money Outside the Mac App Store” is finished. I have published an update of the book to Leanpub edition and the one you can get directly from my website. The print edition is still work-in-progress, but I should have something available later this month.
The following I decided to cut from the update to my book, Make Money Outside the Mac App Store. I came up with a list of arguments that you can apply to your business model and app if you haven’t decided if you want to embrace or ditch the Mac App Store.
Yesterday, Oliver Böhm and I have conducted our Code Retreat Workshop at Macoun 2019. Opposed to the passed-down spirit of Code Retreats, where throwing your code away at the end of each session, our workshop’s participants often wanted to see how the other teams attempted to solve the problem at hand. So we decided to prepare a public GitHub repository. As of now, there’s nothing to see, but I’m curious to find out if the functional programming language tag team will upload their OCAML- and Scheme-based implementations, and which names all the other folks have chosen during the sessions where they had to write tests first.
While I was working on the update of my book, Make Money Outside the Mac App Store, I compiled a comparison of popular e-commerce solutions. My first test reader Sascha found this to be distracting from the books technical objective, so I cut it out.
Another episode went live today – earlier than the last weeks, because I’ll be travelling to Frankfurt for the Macoun conference from Thursday to Sunday.
This chapter was harder to process. There seemed to be parts missing in the story. Maybe I’m too sloppy and haven’t noticed the missing pieces? Either way, something’s amiss in Range land. I also notice that the topics from chapter 1 were connected to the topics here somehow, but it’s just a hunch how things will fit together eventually. I’m looking forward to the next episodes, because I hope it “clicks” and I know how to split the sequence of notes in the structure note up into new Zettel notes and then work with the more powerful web of notes instead of this monolithic book overview.
Episode list: