Matthaus Woolard

Drawings in @exsto@mastodon.art can contain hundreds of thousands of strokes, so re-rendering during pan, zoom and rotation can struggle to keep up.

I wrote about how we keep the canvas responsive: reproject the latest GPU state, render an update with Metal, then correct it again if the gesture moved while the GPU was working.

https://nilcoalescing.com/blog/KeepingCanvasInteractionsResponsiveWithFrameReprojection/

#iOSDev #AppleMetal

Really looking forward to iOSDevUK this September! It’ll be my first talk at an iOS conference. See you in Aberystwyth 🎤

#iOSDevUK #iOS #iOSDev #Swift #SwiftUI #SwiftCharts #AppleDev #IndieDev

@nerius@mastodon.online In my testing on the current iOS 27 betas, we appear to be in luck: as long as you’re using a simultaneous gesture, this fires when the scroll comes to an end. It doesn’t appear to work on iOS 26, though.

To prepare Strolly for app resizability in iOS 27, we wanted its non-modal detent sheets to adapt into side panels on wider displays.

SwiftUI sheets don’t support that presentation, so we built our own panel API. It behaves like a bottom sheet when space is limited and moves to the side when more width becomes available.

I wrote about how we designed and implemented it:

https://nilcoalescing.com/blog/BuildingAdaptiveNonModalPanelsInSwiftUI/

#SwiftUI #iOSDev #SwiftLang

Strolly 1.6 is here!

Show Strolly the areas you enjoy and the places you would rather avoid, helping it find better walks for you. New Home and Lock Screen widgets keep today’s route close at hand.

Get it on the App Store:
https://apps.apple.com/app/apple-store/id6480581550

@connected @viticci for the cameras on AiPods I do not expect these to be used to take pictures. Instead I expect these are purely there to enable gesture based operations. They would then only be looking down along the stem to see users hands. Being able to pause and play audio, confirm or reject a phone call with a distant hand gesture would be compelling and might well go hand in hand with glasses and or a pendent that cant see down just forwards.

@connected The only viable approach to prompt injection attacks is to ensure the LLM that can run actions never gets plain text of inputs. What I should do is schedule another LLM that is constrained to just returning a priority value (0 to 10) (with a clear history for each email) then a script (JS/shortcut etc) uses to sort each email based on its ID and priority value. Then the worst a prompt injection can do is get an email to be higher priority than it should be.

@connected @viticci you are very much correct, the opinion that all indie devs hate Apple and will not makes apps for iOS does not line up with the experience I just had at iOS dev SG last week. The bubble of vocal people on mastodon is a tiny minority and even many of them while being vocal are not switching to make apps on other platforms.

@imyke @connected @viticci they have no other option and intends themselves are a perfect place to start. They provide a static strongly typed interface that already has runtime constraints etc. it is more likely you get a dev to support intents than embed a MCP server within each app on the phone (this each app would need an always running MCP server all the time, apples chips are efficient but not that efficient ).

@connected @viticci @imyke I don't think apple can use MCP Many vendors these days are moving away from MCP. Having the output of commands feed back through the LLM that is creating follow up controle flow is just not safe (it is also slow) It means any content (email subject line etc) can (and will) alter the controle flow with prompt injection. The solution is to have the LLM create a script than runs. For apple this would be have an LLM create a ad-hock mutli step shortcut that runs.