Kino: Pro Video Camera

If you stick to the high level "Hey, take a photo for me" APIs, it isn't a problem. If you want to take advantage of hardware specific features, the iPhone camera system varies from generation to generation, and sometimes within a single generation. On top of this, the AV frameworks have a mountain of undefined behavior which easily breaks with iOS updates. There are tons of iOS and model specific code branches that have cropped up in Halide over the years.

That said, it doesn't hold a candle to Android fragmentation. It's a major reason we will not touch the platform.

There's two possibilities.

1. They're using the crash reports provided through App Store Connect. These are stack traces with no personally identifying information. You can enable/disable these under Settings > Privacy & Security > Share With App Developers.

2. They're using a third-party crash reporter. Under the covers these are often based on PLCrashReporter or KSCrash. A few such as Firebase (previously Crashlytics) implement their own exception handlers/stack unwinders. These are typically anonymized, but at this point it's the app (or the crash reporting SDK it includes) to decide exactly what to report. Most apps will try hard to avoid PII because that's easier than dealing with GDPR, CCPA, ATT disclosures, etc.

> As soon as the crash reports come in

This leads me to believe it's (1) since third-party crash reporters usually send in the crash reports as soon as the app has restarted, while Apple delays crash reports in App Store Connect. In which case the app itself isn't collecting anything: it's iOS and you choose to opt-in when you first setup the device.

It's a 4 letter word, commonly used in internet slang to refer to a good film.

I saw the announcement pretty early on and when I started typing in "kino" into the App Store search, the first autocomplete suggestion was the rest of the app's title in the listing "- pro video camera", and if I clicked that one it showed the app first (well, first result after an ad)

Their privacy manifest shows that they do not collect any data. So they are either not using Firebase or similar for crash analytics, or their privacy manifest is inaccurate and should be reported.

We must specify that we're collecting diagnostics (apart from the ones Apple collects on our behalf for opt-in users) even if they aren't attached to PII or user identifiers. So if they're doing this honestly, it indicates they are relying on Apple's opt-in crash analytics exclusively.

In my experience at least 80-90% of users are NOT opted in to sharing usage analytics with Apple, so they won't receive most crash reports unless they're collecting them through an undisclosed backdoor.

Speaking of infinite updates forever, I am frustrated that software publishers and users have come to expect that all software should either be free, subscription-based, or a one-time purchase with permanently free updates. Each of these models can make sense for different kinds of software-based products and services, but they are problematic in the case of standalone tools (such as cameras, multimedia editors, productivity software, etc.) Some of the problems:

a) Free: Due to lack of revenue, the company that makes your favorite tool may stop developing new features, add intrusive ads, sell your personal data, and/or sell itself to a nasty buyer that will end up killing your tool’s future in one of various ways.

b) Subscription-based: Many software tools are naturally products, not services, yet this model can artificially and unnecessarily turn them into services. Users may end up paying too much over the long run, the software publisher is not necessarily motivated to keep improving the tool, and if the company or a future owner decides to kill off the product, you won’t be able to keep using it (regardless of how much more you’d be willing to pay to do so.)

c) One-time purchase with permanently free updates: Though it provides the software publisher with revenue and users may appreciate the ability to keep using the tool they bought forever, the product may experience market saturation at some point, and the publisher may stop receiving revenue from new users. The publisher will not be motivated and/or financially able to improve the program and may be tempted to switch to the subscription-based model.

I really wish more companies would go back to the old-style model where users can buy the current version of a software tool but would need to pay a discounted price to upgrade to a newer version of that tool (a major-version upgrade.) Along with this, customers would get free upgrades for a limited time (such as year) or all minor upgrades during the current major version. I believe this model creates a healthy incentive for a software publisher to keep improving its products while receiving revenue from both new and existing customers (reducing the market-saturation problem.) Unfortunately, both publishers and especially users may have grown unaccustomed to this model and may not appreciate its benefits.