5 ms·

Sorry you ran into that. I distinctly remember testing the 13 mini, due to notch layout issues, so this is unexpected. As soon as the crash reports come in, we’

Sorry you ran into that. I distinctly remember testing the 13 mini, due to notch layout issues, so this is unexpected. As soon as the crash reports come in, we’ll dig into that. Unfortunately, while we had a QA person on this, and nearly 100 beta testers, the iPhone camera APIs are a mine field. We’ll get a fix out as soon as we have details.

danielskogly 2y ago
Same issue on my iPhone 13 mini 17.5.1, tried with Sando. Crashed immediately after beginning filming
- halostatue 2y ago
  I tried with my iPhone 12 mini 17.5.1 BNW. It didn't crash, but it looked like it had and then came back with a weird error (sorry, I didn’t capture it). My phone is due for an upgrade soon, so it’s not a big deal at the moment.
ungamedplayer 2y ago
I heard that the iPhone landscape was not fragmented though.
- frogpelt 2y ago
  That is a comment usually always stated in comparison to Android hardware. Would you say those two are equally fragmented?
  - ungamedplayer 2y ago
    I don't write for either. An API is an API though.
- zamadatix 2y ago
  Definitely fragmented, even within the same generation and software version there are clearly meaningful hardware differences, but more like "dry mud" cracked apart than "grand canyon" cracked apart in comparison to other options. Still something you have to deal with though, no getting around that.
- sandofsky 2y ago
  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.
infinitedata 2y ago
This looks really promising, hope all goes great! My only concern is reading that you do collect crash reports despite being privacy-focused. How much information is there to identify the picture/video taken or the device/person?
- js2 2y ago
  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.
  - wahnfrieden 2y ago
    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.
  - sandofsky 2y ago
    Yup. We just use Apple’s crash reporting system.

danielskogly 2y ago

Same issue on my iPhone 13 mini 17.5.1, tried with Sando. Crashed immediately after beginning filming

halostatue 2y ago
I tried with my iPhone 12 mini 17.5.1 BNW. It didn't crash, but it looked like it had and then came back with a weird error (sorry, I didn’t capture it). My phone is due for an upgrade soon, so it’s not a big deal at the moment.

ungamedplayer 2y ago

I heard that the iPhone landscape was not fragmented though.

frogpelt 2y ago
That is a comment usually always stated in comparison to Android hardware. Would you say those two are equally fragmented?
- ungamedplayer 2y ago
  I don't write for either. An API is an API though.
zamadatix 2y ago
Definitely fragmented, even within the same generation and software version there are clearly meaningful hardware differences, but more like "dry mud" cracked apart than "grand canyon" cracked apart in comparison to other options. Still something you have to deal with though, no getting around that.
sandofsky 2y ago
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.

infinitedata 2y ago

This looks really promising, hope all goes great! My only concern is reading that you do collect crash reports despite being privacy-focused. How much information is there to identify the picture/video taken or the device/person?

js2 2y ago
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.
- wahnfrieden 2y ago
  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.
- sandofsky 2y ago
  Yup. We just use Apple’s crash reporting system.