I would like to share some feedback regarding the current App Store pricing model, particularly around subscriptions. Over time, there has been a noticeable shift from one-time purchases to subscription-based pricing for nearly all types of apps and games. While subscriptions make sense for content-driven services such as streaming (movies, music, books, etc.), they often feel forced or excessive when applied to standalone apps or games that previously used a one-time purchase model. Many users view this as an abuse of the subscription system, leading to frustration and distrust. As a developer, I also understand the challenge of sustaining revenue, especially when major updates require significant time and resources. One-time purchases often don’t reflect the long-term value an app may provide or the cost of continued development. That said, I believe a more balanced approach would benefit everyone. I’d like to suggest the implementation of a major upgrade pricing model on the App Store. For example, when a developer releases a major new version of an app (e.g., 2.0, 3.0, etc.), they could offer: A standard price for new users (e.g., $2.99) A discounted upgrade price for existing users (e.g., $0.99) This would allow developers to be fairly compensated for continued innovation while also respecting customers who have already supported the app. Subscriptions could then be more appropriately reserved for content-based services. I believe this model would create a healthier ecosystem for both users and developers, encouraging more sustainable and transparent pricing practices. Feedback Assistant : FB17281833

After 5 years, 6 releases, SwiftUI still miss fundamental feature, lock interface orientation by view (can be by container, modal, …). Many apps for iPhone just want portrait orientation but in some cases needed a modal in lanscape for a photo viewer or video player. Interface orientation options in info.plist just don’t work because will lock all views in the app.

Tested in Xcode 14 and Swift Playgrounds 4. From any part of code we can call a “pause()” function and the app becomes unresponsive and sometimes (after some time) the Mac start heating and the Xcode crash. Code examples: Button("Test") { pause() } class Model { func test() { pause() } } func test() { pause() } Private API? Bug? Security flaw?

“The best way to build an app is with Swift and SwiftUl.” But… Most companies can’t move development to iOS 14/15 and again with iOS 16 we have to wait another year for some basic features: Allow (or block) device orientations (portrait / landscape) by View Pull-down to refresh for ScrollView Custom controls for VideoView MapView custom view for user location, map configurations and other options UICalendarView More ScrollView features (events, zoom, offset control, …) Many of these features can be implemented ASAP. How complicate is to implement map configurations? How many years we have to wait? Developers needs more from your team. Thank you!

This year we hope for a full control of tab bar style like we have in UIKit. But the only changes is about a very important feature to become deprecated. From SwiftUI documentation this initializer is deprecated: init( selection: Binding<SelectionValue>?, content: () -> Content ) How we know the selected tab? How to programmatically change the selected tab? Any new modifier for that?

This is a very very welcome feature, thanks! Namings NavigationStack-> NavigationView NavigationPath -> NavigationStack path (parameter) -> stack ”NavigationView” name is more consistently with TabView, NavigationSplitView but I understand for compatibility. Also “stack” is most correct name than “path”. EnvironmentValue Include a NavigationPath to the EnvironmentValues, uses when we don’t set NavigationStack(binding parameter). This works for 98% of use cases, we don’t want to binding the path to every children (and deep children, …). If someone want custom case they will use the specific parameter. NavigationPath Common Operators Like pop to root and replace last.

Don’t over-engineering! No suggested architecture for SwiftUI, just MVC without the C. On SwiftUI you get extra (or wrong) work and complexity for no benefits. Don’t fight the system.