Thanks! Really glad the Best Shot changes feel useful 🙌
And yes, absolutely — I’d really appreciate the write-up about the site issues. Thanks for spotting those!
Alike 1.3.0 is out 🚀
Best Shot is now smarter — it looks at sharpness, exposure, faces & noise.
And you can now enhance the best photo with one tap, compare with the original, and revert anytime.
https://t.co/GJNSwO3hxj
Alike 1.4.0 is out 🚀
Alike is now on your Home Screen!
New widgets show how much space you can reclaim, your cleanup progress, and what’s left in your photo library — without opening the app.
https://t.co/GJNSwO3hxj
#iOSDev#IndieDev
Alike 1.5.0 is out 🚀
Alike now lives on your Lock Screen too.
See how much space you can reclaim or track your cleanup progress without even opening the app.
Three Lock Screen widget styles. All free 🙌
https://t.co/GJNSwO3hxj
#iOSDev#IndieDev
Just launched my new iOS app — Alike 🎉
Find similar photos, clean up your library, and keep everything private on-device 🔒
Would love your feedback 🙌
https://t.co/GJNSwO3hxj
#iOSDev#IndieDev
Today I’m really proud to launch Kickstart Exchange: a free service that provides advertising for indie app developers. You show small adverts in your app, and in exchange adverts for your apps appear elsewhere – it's a link exchange! https://t.co/QTUHk2ZPVu
Apple's on-device models give us free, private and low-latency inference in Swift. But their performance is limited by device constraints (memory, compute, thermal considerations), and the context window size (8k as of iOS 27 beta 3).
Learn how to overcome these limits with a hybrid AI router based on Apple's Dynamic Profiles:
https://t.co/y4U7r99khg
New on the Kickstart blog: How to user test your app with just 5 people. Five testers, Apple’s three questions, and what to watch for in your tests! https://t.co/95vaEwQFIk
Learn how to pick the right SwiftUI grid:
🧱 Grid for simple two dimensional layouts
📜 LazyVGrid when vertical scrolling needs lazy loading
↔️ LazyHGrid for horizontal collections
https://t.co/eyWL8xYFpe
#SwiftUI#iosdev
SwiftData's underlying store is just SQLite, which means you can inspect it directly from Terminal when something seems off. A handy ModelContext extension makes getting the right command trivial: https://t.co/J4299jyDAf
iOS 27 introduced a new modifier called “presentationPlacement”, which lets us position a sheet in any horizontal direction on screens with a “regular” horizontal size class!
NOTE:
This modifier works on iPadOS and iOS under resizing mode, but in standard iOS landscape mode it shows a full sheet view.
By adding “presentationCompactAdaptation(.none)”, we can also make sure it floats the same as iPadOS in standard iOS landscape mode✌️
iOS 27 introduced a new property called “concentricCornerRadii" for “GeometryProxy”.
This means you can now use “GeometryReader” or “onGeometryChange” to obtain the Concentric Corner Radius values directly.
NOTE:
This also implies we can now use this property to access the screen corner radius directly.
Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things.
I think many of these automations have become even more important now. This is true for a number of reasons.
First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time.
Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time!
Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation.
Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.