Emoji are governed by the Unicode Consortium, not Apple. Start here:
Guidelines for Submitting Unicode® Emoji Proposals
https://unicode.org/emoji/proposals.html
Post
Replies
Boosts
Views
Activity
This is a popular topic lately. See the Recommended reply and link in this thread.
Here’s one recent thread on the topic that includes a link you may find useful.
We have a client that want us to add such button
Gotta wonder what their next example of unfamiliarity with this platform will be.
Is your project configured (by someone) to run a linter as a build step?
If so, is that linter performing auto corrections? (Yikes!)
And if so, is that linter triggering on your structs that contain no instance properties?
(I’m familiar with SwiftLint which has a rule that suggests changing struct to enum when there are only static properties, but it doesn’t trigger on your Padding struct. Maybe a different linter does something similar but goes wrong in your case.)
Having an app abruptly vanish and dump back to the home screen is also known as “crashing.” Why do you want that user experience in your app? The user can always go directly to the home screen or task switch to another app using the standard interactions for doing so.
Here’s an old but apparently still valid document on the subject: How do I programmatically quit my iOS application?
Here it is: Implementing Your Own Crash Reporter. To jump quickly to the section on signals, search for “gaping pitfalls.”
When I say exceptions in Swift, I mean, divide by zero, force unwrapping of an optional containing nil, out of index access in an array, etc.
Those are programmer errors which of course ideally (!) should never occur in shipping code. They are treated as unrecoverable by the Swift runtime. You should make sure to distinguish these from error conditions that can occur due to run time conditions rather than errors not caught at development time. Swift’s error mechanism is designed to handle the latter but not the former.
Consider: if your code tries to execute one of those serious programmer errors, then clearly the app is already off the rails in some way, so any recovery logic you want to attempt may be unhelpful at that point. The app should be considered unstable and broken.
In Android, there is the setDefaultUncaughtExceptionHandler method to register for all kinds of exceptions in any thread in Kotlin. I'm looking for something similar in Swift
There is no equivalent in Swift.
Currently, I'm reading about ExceptionHandling framework
That’s for Objective-C. The exception mechanisms of Objective-C and Swift are totally separate.
Read this page carefully: Supported URL Schemes.
Unfortunately, that page doesn’t lead to any documented API for what you are hoping to accomplish.
Read this page carefully: Supported URL Schemes.
Unfortunately, that page doesn’t lead to any documented API for what you are hoping to accomplish.
You may find this thread helpful, particularly this part:
[quote='773887022, DTS Engineer, /thread/742549?answerId=773887022#773887022']
iOS’s underlying Wi-Fi infrastructure assumes that all APs with the same SSID lead to the same network
[/quote]
What random number API are you using? Does its documentation specify its exact algorithm? If not, then there’s always a risk that you are accidentally relying on undefined behavior that could change over time.
That said, I’d be a little surprised if Apple is putting much effort into improving the older PRNG functions such as rand and random (C functions). There’s also arc4random but it’s not seedable, so I’m guessing that’s not the one you are using.
Why doesn't switching from .ascii to .utf8 work? Doesn't this allow for the high bit to be set?
Not all possible byte sequences are valid UTF-8.
Are these crashes being missed by Crashlytics, or is there some issue with dSYSMs in Crashlytics?
This isn’t a specific answer, but if using a 3rd party crash reporter you should start with a little light reading on Implementing Your Own Crash Reporter.
Actually my guess is that the app (not the OS) stored a “this device is jailbroken” flag in the app’s settings, and then never actually checks again to see if the device has become non-jailbroken. This flag would be part of the app data that gets transferred to a new device or restored from backup. If it never actually checks for jailbreak again, then you will be stuck like this forever or until you uninstall the app to delete its saved settings.
And if your device isn’t jailbroken, then it’s a bug in the jailbreak detection that gave a false positive in the first place.
I also tried to contact my bank. They say on their side everything is working fine with the iOS app.
If their app is falsely claiming that your device is jailbroken, then it’s a bug in their app. There’s nothing anyone at Apple or on this developer forum can do to help.
Any idea guys? Is there anything I can „reset“ somewhere?
If I were in your end-user shoes, I’d delete the app and reinstall it so that it there is no saved or transferred data.