-
Notifications
You must be signed in to change notification settings - Fork 5
Guiding Principles
This document describes high-level principles, which should guide design and implementation decisions for the swift_ui package. See technical guidance for specific technical decisions related to these principles.
The most important goal for the swift_ui package is to paint the same pixels, handle the same gestures, process the same text input, and produce the same motion as Swift UI. To the extent possible, the swift_ui package would like to clone those details EXACTLY.
A secondary and lesser priority is to clone or approximate the Swift UI API. This secondary goal only applies if it doesn't conflict with the primary goal.
The swift_ui package should feel accessible and familiar to Swift UI developers. However, the swift_ui package will be used mostly by the existing and future Flutter community. The package will be integrated within apps that ship to multiple platforms, and it will be used by long-time Flutter developers who have never used Swift UI. Therefore, it's critical that the swift_ui package feel as accessible and familiar to Flutter developers as any other Flutter package.
Flutter and Swift UI employ differing stylistic paradigms, e.g., widget composition vs modifier methods. By committing to these stylistic paradigms, Flutter and Swift UI have baked these assumptions into their build, layout, and painting pipeline. Attempting to force a full Swift UI style upon Flutter might require numerous hacks, and might have negative performance implications.
When dealing with fundamental and pervasive practices, prefer and respect Flutter's existing and proven fundamentals.
Should such situations arise, the swift_ui package should make decisions that promote the opportunity for the Flutter organization to deprecate Cupertino in favor of the swift_ui package.