@bill201207 found that UINib(nibName:bundle:) is a big part of the poor performance when our app launches.
Ultimately batching updates will help with a lot of things like this, but really that'll just be masking some of the performance issues so it's useful to find issues like this now.
When displaying an alert in SwiftUI, if the value used to calculate whether the alert is presented is both Optional and does not conform to Identifiable1 it is often recommended to use a separate flag, similar to:
struct ContentView: View { @State private var alertText: String? @State private var isPresentingAlert = false var body: some View { Button("Show Alert") { self.alertText = "Alert Text" self.isPresentingAlert = true } .alert(isPresented: $isPresentingAlert) { Alert(title: Text(alertText!)) } } }
There are 2 main downsides to this:
alertText is not set back to nil, which may cause bugs and will increase memory usage (even if only a little in this case)isPresentingAlert flag needs to be managedTo work around these issues I create a small extension to Binding the allows this same code to be updated to:
struct ContentView: View { @State private var alertText: String? var body: some View { Button("Show Alert") { self.alertText = "Alert Text" } .alert(isPresented: $alertText.mappedToBool()) { Alert(title: Text(alertText!)) } } }
The extension is fairly small and simple:
import os.log import SwiftUI extension Binding where Value == Bool { /// Creates a binding by mapping an optional value to a `Bool` that is /// `true` when the value is non-`nil` and `false` when the value is `nil`. /// /// When the value of the produced binding is set to `false` the value /// of `bindingToOptional`'s `wrappedValue` is set to `nil`. /// /// Setting the value of the produce binding to `true` does nothing and /// will log an error. /// /// - parameter bindingToOptional: A `Binding` to an optional value, used to calculate the `wrappedValue`. public init<Wrapped>(mappedTo bindingToOptional: Binding<Wrapped?>) { self.init( get: { bindingToOptional.wrappedValue != nil }, set: { newValue in if !newValue { bindingToOptional.wrappedValue = nil } else { os_log( .error, "Optional binding mapped to optional has been set to `true`, which will have no effect. Current value: %@", String(describing: bindingToOptional.wrappedValue) ) } } ) } } extension Binding { /// Returns a binding by mapping this binding's value to a `Bool` that is /// `true` when the value is non-`nil` and `false` when the value is `nil`. /// /// When the value of the produced binding is set to `false` this binding's value /// is set to `nil`. public func mappedToBool<Wrapped>() -> Binding<Bool> where Value == Wrapped? { return Binding<Bool>(mappedTo: self) } }
The extension isn't tied directly to showing an alert or a sheet and can be used in any context, but this is one of the better examples of its usage.
This extension is available on GitHub under the MIT license.
1 If it does conform to Identifiable use alert(item:content:)
This adds the ComposedLayout and ComposedUI packages, which will close #16.
The base for this is 2.0-beta, which we can use for testing new changes, which can also break API.
If you go to the repo settings you can (temporarily) set the default branch to 2.0-beta and we can add a note to the README stating this is the beta release and the stable release is available in the master branch.
Once merged and these changes are made the READMEs for ComposedLayout and ComposedUI repos can be updated to point to this repo and their repos archived.
This is a new type of section that is similar to ComposedSectionProvider, but rather than flattening each of the children in to a single SectionProvider it flattens them in to a single Section.
The ComposedUI side of this has been updated to support multiple cells per section, with a convenience for FlatSection that delegates the calls to each of the flattened sections.
This is a breaking change since the protocol requirements have changed. I have set the base of the PR to merge-all-libraries since that's also a breaking change and this PR relies on those changes.
edit: We've moved to our own fork to allow for more rapid development. The latest changes are in https://github.com/opennetltd/Composed/tree/feature/FlatSection, which will eventually be merged back in to this repo once some of the other PRs/issues have been resolved.
In my open source frameworks I usually use the last major Xcode (currently 11.7), latest (currently 12.3) and latest beta (soon to be 12.4), but this project has only been setup for the latest version of Xcode.
If we feel it's good to run the tests across multiple Xcode versions I have created https://github.com/JosephDuffy/update-xcode-version-action, which we can use to keep the versions in-sync with the versions available as part of GitHub actions.
For now I've removed all use a explicit Xcode versions.
Regression introduce in 1.1.1.
Would occur when a segmented provider was the last child of a composed provider and the selected segment changed.
This could have also been fixed in SegmentedSectionProvider but changing the _currentIndex after the delegate has been notified (which is closer to what ComposedSectionProvider does) but we have nothing in the API contract stating this must be done, so really it's an issue with the caching in ComposedSectionProvider.
These properties are accessed quite frequently and can be cached with a little extra processing.
This is another finding from screens that have a large number of composed sections.
This and https://github.com/composed-swift/ComposedUI/pull/15 seem to be the main areas of performance issues, although that doesn't mean that once these are working and merged we won't uncover more 😅
Thanks to @bill201207 for their contributions to this change.
The idea of this is that without breaking the API the collection view will batch updates.
Inserting a large number of sections is the main area of performance loss we are currently encountering, because the sections are inserted individually and not batched. This change alone has reduce the initial load time of one our screens (which has 100-150 sections added at once) from 30-45 seconds down to less than a second (at least it is not noticeable).
I had created https://github.com/composed-swift/Composed/pull/17 to try and address this, which has the advantage that it would apply to other view types (e.g. UITableView), but I believe does not offer the same performance improvements and it is restricted to a single ComposedSectionProvider.
This is a draft to collect feedback; as you can see there are some TODOs but I think there's enough implemented to provide an overview of the changes that would be required to implement this.
This does not currently work; there are situations that cause the collection NSInternalInconsistencyException', reason: 'Invalid update error. I have some failing tests that demonstrate what the result should be.
When adding a lot of sections (we have a screen which inserts 100~175 on initial load) the performance is quite poor.
Along with the improve-composed-section-provider-performance branch (which I want to fully validate before making a PR) performing these changes in batch helps a lot.