{"id":27894,"date":"2020-01-20T15:34:19","date_gmt":"2020-01-20T20:34:19","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=27894"},"modified":"2020-02-24T15:45:10","modified_gmt":"2020-02-24T20:45:10","slug":"rejected-for-working-around-macos-bugs","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/01\/20\/rejected-for-working-around-macos-bugs\/","title":{"rendered":"Rejected for Working Around macOS Bugs"},"content":{"rendered":"

Daniel Jalkut<\/a>:<\/p>\n

\n

It’s a dramatic day for @MarsEdit and compatiblity, as App Review has suddenly become more interested in private WebKit SPI. I patch WebHTMLView to work around serious bugs which I have filed. One of them is a crasher. I don’t think WebKit1 is the best focus for App Review?<\/p>\n<\/blockquote>\n\n

A truly unfortunate situation to be in as a developer. Apple will likely never fix the bugs, as WebView<\/code> is now deprecated. Its replacement, WKWebView<\/code>, is not fully ready yet, and will require a complete rewrite in a different language to get the same functionality, if that’s even possible.<\/p>\n\n

Daniel Jalkut<\/a>:<\/p>\n

Spending my whole weekend, apart from celebrating the delightful birthday of my little baby 8yo, working around issues that App Store review put on my plate. The price I pay for playing this game, I know. I just wish the game were a little different.<\/p>\n

[…]<\/p>\n

Overall I am pretty chill about App Store review and the goals of bringing developers into line. I do think it would be massively improved by a graduated system of warning of future rejection while allowing immediate fixes to pass through.<\/p>\n

As a Mac App Store developer whose apps have been in the store since the beginning, it’s not a great feeling to know that any critical update might be held up because Apple decided to get more uptight about something that was OK for the past 8 years.<\/p><\/blockquote>\n\n

Daniel Jalkut<\/a>:<\/p>\n

Generally I would say the thing for other developers to look out for is Apple may be improving its ability to detect things like patches as opposed to outright “use” of private API, and they may also be getting less forgiving of some behaviors, even if in the name of better UX.<\/p><\/blockquote>\n\n

This is the thanks you get for filing Radars and putting up with bugs for all those years.<\/p>\n\n

It’s not exactly altering the deal<\/a> because the Mac App Store has always banned private API. As was said at the outset<\/a>, this is not realistic. There will always be (different) OS bugs. Even in the best case, they will take time to fix<\/a>. Nobody—not customers, developers, nor Apple—wants apps to exhibit bugs, but that’s the inevitable result of a policy that forbids patching to work around buggy API.<\/p>\n

When the Mac App Store debuted with this policy, some people said it would force Apple to fix the bugs faster. I don’t think that’s happened. Rather, developers kept doing what they were doing—I bet most large or popular apps are using private API to work around bugs—and Apple either failed to detect this or chose to look the other way.<\/p>\n\n

Now, the rules haven’t changed, but perhaps enforcement has. This is a problem both because of increased user-visible bugs and fairness. Some apps like MarsEdit will eat up development time to end up with something buggier than they started with. Other apps will get a different reviewer and slide right through. Apps that Apple deems sufficiently important will be exempt from the rule.<\/p>\n\n

With out-of-process Web views, increasing use of Swift, and direct Objective-C properties, patching will be more difficult. This will level the playing field—but to the lowest common denominator.<\/p>\n\n

Daniel Jalkut<\/a>:<\/p>\n

\n

My compromise build was approved by Apple this afternoon. I found another way around one of the bugs I was fixing, but have no fix for the other one, yet. It’s a fairly minor thing, but the Mac App Store version is now buggier than it was, thanks to App Review.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n