| From what I've seen how apple did it: 1. They added optional nullability syntax to objective-c, a language that assumes everything is null and doesn't crash when you send a message to nil. If your file uses nullability, it's required for the file, otherwise you don't have to use it. Code without nullability annotations using non-null annotated code could interface with the non-nullable code. Errors didn't come up unless you did very obvious things like directly put nil in a non-null argument. 2. They migrated their entire apple library base to have proper nullability annotations. Code that didn't have nullability annotations continued to work fine. Or I think you could just turn off the build error with a compiler flag. 3. Apple introduced swift. Any objective-c code that didn't have nullability defined was assumed to be an implicitly unwrapped non-null. So if you give a null to something not expecting a nil in swift, it would crash. Apple has a blog article specifying it further here: https://developer.apple.com/swift/blog/?id=25 ----- I liked this approach for the most part. Migration wasn't that much of a pain, and it was incentivized because I didn't want implictly unwrapped stuff in my swift code. If you migrated the flutter framework and the dart stdlib to have nullability, then new projects can start with proper nullability annotations from the start, while old projects can progressively migrate files as needed. Java also has a nullable syntax annotation, and kotlin probably has some sort of java-kotlin nullability interop somewhere. I would really suggest doing it, nullability has given big stability benefits to large projects as it is, and would help adoption in the future as people using something like kotlin & swift for new projects vs flutter itself. |