(and how to create solutions that continue to work after updates)
“Apps may only use public APIs and must run on the currently shipping OS.” Apple App Review Guidelines
If you’ve ever started working with a new framework and found yourself thinking: “Now I’ll understand everything myself, reading the documentation is too long,” you’re definitely not alone. Many of us have a natural investigative instinct: try first, and only then look at the instructions. And that’s completely normal.
However, at this stage it can be easy to get carried away and end up in a situation where the code works great, but perhaps relies on non-obvious features of the system.
Why is it sometimes not enough to simply “figure it out on your own”?
Frameworks, especially closed ones, are complex and multi-layered systems. They often hide internal logic and optimizations that:
* are not described in public documentation;
* do not guarantee that behavior will be maintained in the future;
* may change with the release of new versions;
* may contain features known to the developers that have not yet been fixed.
When we act intuitively, there is a risk of building architecture on random observations rather than on documented rules. This can make the code more sensitive to updates.
Documentation is not a limitation, but a reliable support
Framework developers create manuals to help us. Acting within the documentation, we get:
* stability;
* support;
* predictable system behavior.
By going beyond these limits, we take on additional risks, and maintaining such code becomes more difficult.
Experiments? Certainly. But with an understanding of boundaries.
Curiosity is a great trait to have in a developer. Exploring and trying new things is absolutely essential. But here is a small wish:
The most comfortable way to experiment is to rely on best practices.
The documentation is a map that shows which paths are the most secure and supported by the creators.
An outside perspective: expert advice
We often learn from experienced colleagues:
* they conduct useful courses,
* speak at conferences,
* write wonderful books and blogs,
* share their unique vision.
Many of them share truly valuable experiences. But it is worth remembering: if the author’s approaches contradict the official documentation, they may turn out to be fragile.
Such “empirical patterns” sometimes:
* work only on a specific version of the framework;
* sensitive to updates;
* may behave unpredictably in unusual situations.
Learning from the community is great and rewarding. But any advice, even the most authoritative, should always be carefully checked with official manuals.
A little about SOLID
Three ideas from the SOLID principles perfectly complement this approach:
* Open/Closed Principle: Try to extend behavior through public APIs and, if possible, not depend on hidden implementation.
* Liskov Substitution Principle: Rely on the contract, not the specific implementation. Otherwise, changes under the hood can lead to unexpected difficulties.
* Dependency Inversion: build dependencies on abstractions, not details.
In practice, this means that being tied to internal, undocumented details of the framework makes the system brittle.
Based on public interfaces and contracts, we get:
* better isolation of code from changes in the framework;
* ease of testing;
* predictability and reliability of the architecture.
What if there is a bug?
It also happens that everything is done according to the rules, but the result does not meet expectations. Frameworks evolve and are not always perfect. In such cases:
* Build a minimal example that reproduces the problem.
* Ensure that only documented APIs are used.
* Send a bug report – the development team will certainly appreciate your work and try to help.
If the example relies on workarounds, it will be much more difficult for developers to provide support.
How to get the most out of the framework
*Refer to documentation.
* Follow the guides and recommendations of the authors.
* Experiment within the described functionality.
* Check advice from the Internet with official sources.
* Localize bugs while respecting framework contracts.
Conclusion
Frameworks are powerful tools with their own rules of the game. By forgetting about them, we risk making our code overly vulnerable. But we all want the created products to live for a long time and not require urgent corrections after each minor update.
Manuals and documentation are excellent support that helps create truly reliable solutions.
Sources
https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM
Leave a Reply