Toots for babbage@iosdev.space account

Written by Duncan Babbage on 2024-11-06 at 07:08

If you voted for Donald Trump, please unfollow me so I know to unfollow you.

And Americans, I don’t want to hear the words “Leader of the Free World” ever again. It’s bullshit and at this point you absolutely don’t deserve to keep rolling it out. #uspol

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-26 at 03:59

Builds are processing so much faster after upload to AppStoreConnect than they used to, mere seconds.

Either they have substantially sped up something at their end, or my progressive upgrade and removal of old code and resources from my app has removed something that was previously slowing things down.

Either way, I love the result, and @intro v2.0.3 with significant performance improvements for background sync operations is now in review. #iOSdev #IndieApp

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-25 at 23:39

Ah damn, looks like it's a SwiftUI bug: https://forums.developer.apple.com/forums/thread/758922

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-25 at 23:29

Trying to use the new #SwiftUI .onScrollPhaseChange on a List… No matter which level in my view hierarchy I’ve tried attaching it I get an initial call to the closure with an .idle state but no phase changes are reported when scrolling…

Anyone encountered this? #iOSDev

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-25 at 19:16

I have a #SwiftUi view with an .onReceive handler that triggers an update to a fetchRequest when relevant additional data has been added in the background.

If the user is scrolling when the change is integrated there’s a tiny hitch. What I’d like to do is detect if the user is scrolling and defer the update until scrolling stops.

Is there a good mechanism to implement this in SwiftUI? I already have a debounce system so I guess I need to add an ‘is the user scrolling now’? #iOSDev

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-25 at 09:06

I simply ended up in this situation because I hadn't originally had the refetchTrigger in place, and so failed to learn that the earlier step of pinning the query generation and refreshingAllObjects() was both completely unnecessary and additionally was indeed the cause of my performance problems.

There’s nothing like the satisfaction, joy even, of solving a significant performance issue. 🎉

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-25 at 09:03

It transpires this was completely superfluous, it appears, and highly problematic performance-wise.

I already had viewContext.automaticallyMergesChangesFromParent = true in my setup, so the context was being updated automatically.

All I had to do was prod my list with a stick, setting a new UUID on my refetchTrigger I passed to the view. That correctly causes the list to refetch when relevant objects have been imported. And since it turns out they were already in the viewContext, sorted!

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-25 at 09:01

Ah awesome, it looks like I have solved this. Turned out, essentially, that I was just doing far more work that I needed to. I realise now how this happened. Because originally I hadn’t found the mechanism to ensure my SwiftUI list was updated when there were additional objects in the viewContext, I’d thought from research I had to do a heavy:

`try? viewContext.setQueryGenerationFrom(.current)

viewContext.refreshAllObjects()`

…once I’d finished background processing. 1/3

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-24 at 22:03

I just feel the need to say, since I’m working my GST return, that Microsoft is a US$3.17 trillion company, but if you could download a series of six monthly invoices from @intro they would be called: Intro-2024-04.pdf through Intro-2024-09.pdf

…not:

E0305RWD0S.pdf E0320S9FK2.pdf E0310SPV8P.pdf E0310T1EF3.pdf E0309VEOVX.pdf E0302TTEJ6.pdf

Love the way they keep all that money razor focussed on the user experience.

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-24 at 04:09

So... I’ve traced my performance issue down to the way I’m updating my main SwiftUI lists in response to incoming NSPersistentStoreRemoteChange #CoreData notifications from iCloud. I was processing them on a background context, then sending notifications observed by lists. If they displayed types that were updated they’d refresh.

Clearly I was not doing this well because the view-side-subscription-and-refresh part could cause multi-second UI pauses. Obv not great.

Advice welcome. #iOSDev

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-23 at 01:52

The biggest challenge with this is I’ve seen the app crash three or four times in testing this in large sync operations but it’s very infrequent (thousands of transactions fine then a crash), and so impossible to reliably test at this stage. The only thing I’ve proven to myself is it can happen both when the app is in the foreground and background, so it’s not dependent on whether a particular SwiftUI view that is responding to the fetch is visible on screen. Which is nearly no lead at all.

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-23 at 01:50

I know with Core Data sync operations sometimes properties that otherwise always have a value (e.g., there’s a default set) are null, and my best guess is the bitwise operator chokes on that during change processing?

For now, will prob stick with OptionSet but just restructuring to not use a bitwise operator, by focussing on specific cases I need, e.g.,

          format: “options == %i OR options == %i",
          options.rawValue,
          MyOptions.all.rawValue
  )`


=> /toot/113354226127868246 More informations about this toot
=> /thread/113354226127868246 View the thread

### Written by Duncan Babbage on 2024-10-23 at 01:46
It’s pretty easy to define a #SwiftLang OptionSet & then store it in a #CoreData Int using a custom getter and setter. 

Testing suggests it’s possible to fetch based on specific option, i.e. NSPredicate like:

…which works great till app crashes during iCloud sync with something like: "Exception was caught during Core Data change processing. [snip] Can't do bit operators on non-numbers with userInfo (null)”

Thoughts? #iOSDev

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-22 at 21:38

@intro for clarity, Intro wasn’t the foreground app at the time, I was doing something else on the phone. The TestFlight crashes section doesn’t show a stack trace of any kind… seems like TestFlight won’t have stack traces for certain kinds of terminations including ones by watchdog?

I should maybe go back to having some other crash reporting tool. tbh it was so nice to remove all of Firebase given I was only using Crashlytics but maybe I should bring it back… 🤔

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-10-22 at 21:35

I had a new build of @intro already submitted for review and installed the build via TestFlight onto my carry phone. However, I pulled the build when TestFlight popped up notifying me that Intro had crashed and asking if I would like to notify the developer.

It looks to me like possibly this was simply iCloud Core Data sync continuing to run in the background so long that the app was terminated by the watchdog. Is it correct that TestFlight might report that as a crash? #iOSDev

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-09-30 at 01:41

I wondered whether explicitly setting view identifies would also solve this but didn't seem to. I tried multiple combinations of how to set the identifiers on the RowView instances and this did not stop the example from rendering the full 6,500 rows representing the full collection.

I don’t recall coming across this .equatable() view modifier prev. I am unsure if the lack of this is triggering a bug in SwiftUI or demonstrates expected behaviour. But I bet this is a commonly experienced issue.

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-09-30 at 01:38

I appear to have cracked this. By conforming RowView to Equatable plus then appending to RowView the .equatable() view modifier, the View loads just 18 rows... only one or two more than initially appear on screen.

Based on this, it seems even the previous 37 was probably rendering all visible views twice...

This looks like a great solution if it lets me continue to use subviews while addressing the performance issue.

UPDATE: See this important explanation: https://indieweb.social/@curtclifton/113273571392595819

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-09-29 at 23:46

Interesting finding on a #SwiftUI performance issue. Made a sample app to test. With a 6,500 item collection, if I have a List containing a ForEach and call a RowView() within that ForEach that defines the row contents, the body on RowView is called 6,500 times indicating 6,500 rows are rendered.

If the identical contents of that RowView are placed directly inside the ForEach, only 37 rows are initially rendered, when 17 fit on the screen.

I’m unclear why. Would love any insights. #iOSDev

=> More informations about this toot | View the thread

Written by Duncan Babbage on 2024-09-16 at 00:57

At the finalising screenshots stage of Intro 2.0, my app for things you want to remember. This complete redesign and reconceptualisation has been a long time coming and I am thrilled to be releasing it this week. #iOSDev #indiedev

=> View attached media

=> More informations about this toot | View the thread

=> This profile with reblog | Go to babbage@iosdev.space account