This. People who don't fully understand the software development life cycle don't seem to understand why some developers might be upset with this mic drop release date and being caught off guard. . . . . .
Just to be clear, I am not upset at the drop date. Apple has always, at least recently, done this. Whether it is 10 days or 1, Apple does not provide the tools to allow small developers to make sure their Apps work on day 1 of a new OS release. Period.
Big developers have inside information, they have ex-Apple employees, they can call Apple and get real answers. Small developers cannot.
Users can blame developers all they want, but the truth is that a lot of the time Apple could have prevented the break, but choose not too. Sure there are bad developers that don't care, but most do.
What are these tools Apple could have provide, but choose not too?
1. Make sure API changes don't break existing code. Give the API a new name for new behavior, etc. How do you think it is possible for linux to run 10 or 20 year old code? Heck, I even ran 40 year Fortran code recently on a non-Apple device. This is not rocket science and the way to do it has existed for a really long time.
2. Give clear release notes with details, so developers don't have to determine experimentally what the changes are.
3. Make development tools with fewer bugs. We always start testing with new beta versions of the development tools and hope our experience will change. When they are so buggy we cannot continue we quit and wait for the general release. This has happened with every recent release of Xcode.
4. Make automated testing tools that don't break testing code with every release. We had a lot of breaks with Xcode 12 that we still have not fixed. We are spending the time fixing code that broke.
5. Separate development tools from SDKs. Changes in SDK should not require new development tools. Apple even operated this way prior to Xcode.
6. Provide simulators that actually simulate real devices. Sure, Apple's simulators are orders of magnitude better than a few years ago, but everything still has to be tested on real devices. A bug on an Apple simulator does not mean a bug on an Apple devices. For example. Xcode 12 GM simulator still refuses to show the software keyboard at times. How can you test code when the keyboard will not show. Such basic problems are the hallmark of the new Apple.
7. Start fixing bugs. We quit providing bug reports to Apple because they sit with no progress and it takes a lot of time to prepare a repeatable test case. It is no longer worth our time.
8. Update the developer documentation. We use official public APIs that have zero documentation about how they work. The documentation is simply a listing of the function name and arguments. This means that for some APIs we have to write several test routines and spend hours just trying to figure how the API actually works in practice and even then we cannot be sure of errors or other oddities that we did not realize applied.
In addition, the developer videos often contradict the released developer documentation and always contain information not in the developer documentation. Do you realize how time is wasted watching a 45 minute video every time you need to figure out how something is supposed to work, rather than just looking up the API in the documentation?
I could go on, but any reasonable person should get the point. If Apps break on a new release, it is 90% Apple's fault and they should be held accountable. If users decide not to hold Apple accountable, then there will be no reason for Apple to improve. It's up to the users, developers have no say. You want App breaks, then just continue to blindly support Apple and shout down all criticism.
