That spinner persists for abour 3-4 seconds, during which I can’t click on anything or interact with Obsidian in any way. While it’s a neat trick to have this “instant startup”, I actually prefer the old behavior where as soon as the UI appeared it was usable. General UI guidelines say don’t present a UI until it’s ready to be interacted with.
I noticed this as well in my two main vaults yesterday and thought it strange – mostly because I had never seen the spinner before in Obsidian (that I can recall). I’m getting it for about 2-3 seconds, so a bit better.
I’d ask about it in the Discord’s #insider-desktop-release channel to see if it’s expected behavior or not.
SYSTEM INFO:
Obsidian version: 1.15.1
Installer version: 1.14.5
Operating system: Darwin Kernel Version 27.2.0: Thu Oct 15 00:02:46 PDT 2026; root:xnu-13432.41.4~25/RELEASE_ARM64_T6000 27.2.0
update: enabling Restricted mode and closing and opening the vault shows the spinner for about a second (in one vault I tested).
Yep, I found that disabling Omnisearch brought my spinning down from 4s to just over 2. Still, I do prefer the previous behavior - wish there was a mode to hide the UI until it is ready to use. Also, I did pop a message onto Discord.
We’re working on making the startup as fast possible, so ideally the solution is that you don’t see the wait cursor at all.
I strongly disagree with the idea of not showing content if it’s not interactive. It’s much better to show useful content instead of nothing at all. It makes your workspace immediately readable and transitions more smoothly into the ready state.
Almost all good apps? It’s an age old UI principle that the Apple HIG still advocates:
Show something as soon as possible. If you make people wait for loading to complete before displaying anything, they can interpret the lack of content as a problem with your app or game. Instead, consider showing placeholder text, graphics, or animations as content loads, replacing these elements as content becomes available.
Funny, I was going to link you to that same URL… on that page under the Best practices heading, it says:
“Let people do other things in your app or game while they wait for content to load. Loading content in the background helps give people access to other actions. For example, a game could load content in the background while players learn about the next level or view an in-game menu.”
So I agree with you (and Apple) the idea of showing something … but what that something is important and changes the context:
showing a splash screen, loading window, progress bar etc
showing the final UI exactly as it would appear when in ready state but where the user cannot click or interact with any element
I know there’s a tiny progress bar at the bottom right of the window, but unless you know to direct your eyes there, most users will miss it.
I see 3 ways this could be solved:
move that “Loading…” progress bar to a floating modal in the center of the UI, clearly showing that it’s still loading and not ready to use yet
somehow figure out a way to do all the plugin or cache loading in the background so the UI can become interactive within 1 second if you are going to show the ready-state UI immediately
allow the user to toggle the instant load behavior and revert to the “old” method
“Users expect your app to remain responsive while it performs computation, regardless of the type of machine. This means different things for different apps — providing realistic physics, loading data from disk or the web, presenting complex scenes, navigating between pages, or processing data. Regardless of the type of computation, users want your app to act on their input and eliminate instances where it appears unresponsive.”
Suggestion number 2 is in the right direction. We’ll keep making startup faster so hopefully you don’t notice it, and there may be more parts of the app that become interactive as loading progress. The idea of bringing back a blocking loading screen is not something we will consider, so I am closing this thread. Thank you!
