Are you looking for the device bezel (picture of the physical device) around the display? Simulator doesn’t save that. “Device mask” refers to the rounded corners and the top notch on devices without a home button. Saving with that option renders those areas transparent.

I think most developers would consider 8 GB of RAM too small. Try to get 16 GB at minimum, preferably 32 GB.

The error message means the storyboard is looking for an outlet named saveNotes but your code shows that the outlet is named saveNote.

In addition to accessibility settings, note there’s a global Display Zoom toggle in the Display & Brightness settings (on device) and in the Developer settings (on simulator).

Not possible; see this for details.

Asking here in the forum is proof that the documentation isn’t exactly complete. But we may be able to infer clues from the equivalent newer async method upload(for:from:delegate:). That method either returns a (Data, URLResponse) tuple or throws an error, so we know you’ll never get data or a response in the case of an error. And note the return tuple’s URLResponse is non-optional, so it will always be present if no error. The tuple’s Data is also non-optional but could be empty, so we can’t say for sure if that’s the case in the old version of the method. Probably best to handle both a nil data and an empty data the same way.

Are you sure this isn’t just the behavior where iOS tries to squeeze whitespace to make the label fit without truncation? That’s based on the actual size of the text on screen rather than the length in characters. That said, I tried display name Toronto Hydro on a few different simulators here and it seems ok. The space does get squished a bit on the iPhone SE (1st gen.) but looks normal on larger simulated devices. Are you seeing this problem on all display sizes and all iOS versions? A couple sanity checks would be to: Test with simple cases such as A B and iiii iiii iiii. Test outside your app by making a Home Screen folder, and then manually rename it to Toronto Hydro. I believe folder labels should render exactly the same as app display name. Any difference?

The review guidelines wouldn't specifically mention disallowing reading the phone number because there’s no public API for reading the phone number in the first place. Anything that’s impossible using public APIs is implicitly disallowed.

Ah, so this is only on TestFlight? Could be due to the yellow dot in front of the label. That reduces the available space and could conceivably trigger different shrinking logic. Unfortunately there’s nothing you can do about that, and the same thing will happen when there’s a blue dot after an app update. In fact, now I can get the perfect removal of the space with simple labels of * Toronto Hydro, - Toronto Hydro, and • Toronto Hydro. I think your label text just happens to be just right to trigger this effect when a marker character is prepended.

Sounds like the same issue discussed in this thread.

Not in Xcode, but actually macOS Finder can display them in a friendly format via Quick Look.

The benefit is for you (the developer) not having to support all those old versions, and to be able to use new and improved APIs introduced in newer versions. Do you actually have test devices running all those old versions? That’s a lot to manage. The simulator is great too, but the current Xcode supports simulator versions only back to iOS 12.4. If a user reports a bug on affecting only an older version on a specific device model that you don’t have and don’t have a simulator for, what do you do? And if you release an update, how broadly can you test it? If you want to use newer functionality, do you clutter your code with version-specific conditional logic to make it work? That can get tedious and error-prone. And in cases where newer APIs improve on older APIs (such as, for example, the fantastic diffable data sources for tables and collection views, added in iOS 13) then being unable to use them can be deeply frustrating. And in the Apple world, users adopt newer iOS versions much faster than Android, if you’re familiar with that world. So you’re likely to find the proportion of users on iOS versions 9, 10, 11, 12, and even 13 to be very small (see charts here) and arguably not worth the effort. Our poor Android counterparts have a much tougher time supporting all the OS versions still in wide use on devices of similar vintage.

One could argue Finder is actually a more logical place for this. In Xcode you don’t work directly with .mobileprovision files, so they aren’t present as project files that you could click on and see in an inspector pane. They just exist as free files in a known location. And it turns out Xcode does have a feature to show details for the profile for a target, though it seems to be limited to the profile used by the current scheme’s Run build configuration. It’s a little ⓘ button in the target’s Signing & Capabilities tab.

Sounds like the same issue discussed in this thread.

If you are looking for a feature of the App Store to designate an app update as “required” (meaning the OS would automatically block your old versions from running or automatically install the update) then there isn’t one. The user always has control over app updates. Of course you can implement your own app logic to (for example) query a web API to see if a new version is available, and then degrade your app's functionality, such as displaying a message inviting them to update. But think really hard before doing this: it’s unexpected behavior and a terrible user experience. And of course you would need to have built this version checking functionality into whatever previous version of the app the user already has. Which, since you’re asking the question, probably isn’t the case right now. It’s best to do whatever you can on your back end to keep old versions working as long as possible.