u/Horror_Still_3305

not sure if you guys can see with just image, but the scroll content is able to show underneath the section with the segmented pickers, and this section’s background blends totally smoothly with the toolbar.
from my own attempts, I am not able to make a extra long toolbar, and if i added a row just underneath the toolbar, the effect of scrolling the content under the row does not produce the effect..
I'm just wondering how Apple made this. did they just built the toolbar custom without even using swiftui toolbar?
yes i am aware this is an older version of iOS, but I still want to know. thank you.

In https://medium.com/androiddevelopers/exceptions-in-coroutines-ce8da1ec060c

It talks about how with a SupervisorJob, you can ignore exceptions from a child coroutine, and it does not propagate to its siblings or to the grand parents and so forth. But then it also says “If the exception is not handled and the CoroutineContext doesn’t have a CoroutineExceptionHandler (as we’ll see later), it will reach the default thread’s ExceptionHandler. In the JVM, the exception will be logged to console; and in Android, it will make your app crash regardless of the Dispatcher this happens on.”

But this sounds like it’s saying the app will just crash and everything will die if the exception is not handled; but then whats the point in saving the coroutine family using a SupervisorJob if everything will just die anyway? If they mean I need to implement the CoroutineExceptionHandler for the SupervisorJob to be of use, then the question is, what is the point of having a SupervisorJob…… cuz then every discussion of SupervisorJob needs to marked with an asterisk * (oh btw, you also need to implement the CoroutineExceptionHandler otherwise your Supervisor is useless. )

And why do they explain these things so off-handedly as if it’s so not confusing at all to someone learning?

Based on https://developer.apple.com/xcode/system-requirements
And also trying out xcode 27.1, it seems like ios simulator on ios 16 isn’t supported.

Just wondering what is Apple’s plan for developers to test their apps against ios 16/15.

In his latest letter to shareholders https://www.palantir.com/q2-2026-letter/en/, he writes

“Every organization in the world is awakening to the risks of handing the creators of the language models the keys to their institutions, of letting the models loose within their homes.
The demand from our partners is … for control over data, the prompts that the models ingest, and more fundamentally the organizational and business intelligence, their alpha, that the language labs are not only ready and willing, but structurally designed to capture from their customers..”etc..

What I’m wondering is how big of a problem this really is. If your company uses Microsoft or Google products heavily, allowing their AI models access to your data is not a new problem— since so much of your data is probably stored on Microsoft OneDrive or Google Cloud already.
It can be a problem to use OpenAI or Anthropic products, but again, they will know what the corporate expectation is of them and will need to clean themselves up if they want business.

I just don’t see AI sovereignty as a big problem.

How do they make me a better dribbler? In real games players don’t dribble mindlessly in S patterns.

https://youtube.com/shorts/OT7RhXv1LQY?si=cz1stk2ay4NbjK8d

In https://developer.android.com/develop/ui/compose/lifecycle#composition-anatomy
, they explain that the identity of a composeable instance is its call site, which they define to be “The call site is the source code location in which a composable is called. This influences its place in Composition, and therefore, the UI tree.”

I understand this as being the place in the source file where the composeable is called. But I find that there must be more to it than that, as it’s hard to imagine a robust, efficient system that literally keeps track of the exact line of code where each composeable gets called for a composition. For example, the compiler would have to build out a table for every composeable and store it as part of the build, and if the composeable never gets called in the user session, then it’s just storage space being wasted. I assume the identity of each instance of a composeable is established during initial composition where the Compose layout system behind the scenes builds out some kind of a tree to see the composeables and their location relative to other composeables in same function. Just looking for insights.
Thanks!

I agree with him 100%. Making such claims is harmful rather than helpful. We are not going to get UBI until that happens so why bother saying things that will only cause panic and anxiety?