# visionOS 30Days: forty small Spatial Swift apps as a reference shelf > A self-imposed daily challenge produced forty separate Swift projects for visionOS, one per day, each a working demonstration of a single platform capability rather than a growing application. **satoshi0212/visionOS_30Days** — visionOS 30 days challenge. - Repository: https://github.com/satoshi0212/visionOS_30Days - Stars: 2,231 · Forks: 185 - Language: Swift - License: MIT - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/satoshi0212-visionos-30days ## Forty directories instead of one application The tree is the whole architecture. There are `Day1/` through `Day40/`, plus a `docs/` directory, a `LICENSE` and a `README.md`. There is no shared framework directory, no internal library, and no package manifest at the root. Each day is a self-contained Xcode project. That structure follows directly from the premise. The README describes a 30 days visionOS challenge where the author took on implementing diverse visionOS features, and then notes that they are submitting more for excess content. The name says thirty days, the tree says forty, and the repository description says visionOS 30 days challenge. All three are in the repository, and the discrepancy is explained by that last line rather than being a mistake to reconcile. What this means for a reader is concrete. If you are trying to learn how to place a 3D model in a RealityKit scene, you open `Day4/` and you are not looking at someone else's accumulated abstractions from thirty nine prior days. The cost is that there is no shared library and no unified sample code, so patterns are repeated rather than factored. For a reference shelf that is the right trade. ## What the day by day index actually covers The README table is the most useful part of the repository, because each entry names a capability in a few words. The first days are deliberately elementary: Hello visionOS, Show teapot, Play HLS video, Place box, Textured box, Handle drag and tap, Post to Slack, Attachment and animation, Portal, ImageBoard. From there the list moves through the platform's actual vocabulary. Day 12 is a 2D Map, Day 13 Place axis, Day 14 Progressive and Full view, Day 15 TabView, Day 16 ARKitSession Placement, Day 17 Ornament, Day 18 3D Text, Day 19 Speech Recognition, Day 20 Slack just fetch, Day 21 Immersive look around and Day 22 Immersive look around refined. The later entries show a project learning in public. Day 23 In-room Slack Viewer, Day 24 Immersive 360 video, Day 25 Drag and drop, Day 26 SwiftUI Shader, Day 27 SwiftUI View in ImmersiveSpace, Day 28 SwiftUI View in ImmersiveSpace refined, Day 29 Debug Log View. The pattern of a feature appearing twice, then a refined version, is the clearest evidence in the repository that this was iterative work rather than forty unrelated demonstrations. Ornament is the notable one for anyone watching Apple's platform, since it is the API for placing a SwiftUI view as a persistent 3D object in the shared space rather than inside a window. Seeing it on day 17 of a build-out sequence tells you roughly when the author picked it up. ## The framework mix across the topics and language GitHub reports Swift as the language, which is unambiguous. The topics are more informative: arkit, metal, realitykit and visionos. Those four names line up closely with what the day list actually contains. RealityKit is the scene graph, which is why placement, portals, immersive spaces and 3D text all appear. ARKit covers the device camera, plane detection and session placement, which is what Day 16 and the placement-oriented days are about. Metal is the low level graphics API, and it appears through the shader day and the textured geometry work rather than as a standalone topic of its own. There is no SwiftUI topic, even though several days explicitly involve SwiftUI views, which tells you SwiftUI is treated as the default rather than the subject. This mix matters for judging whether a day is current. Apple renamed and reshaped parts of this surface area, and a sample built against an older RealityKit or ARKit API may not compile cleanly against the current SDK. The repository has no version tags and no releases to tell you what was current when each day was written, so the reliable signal is the linked post rather than the file itself. ## Each day links to the post that came with it Every row in the table pairs the day title with a link to a post, and a screenshot image hosted in the repository's own assets. Most of the post links point at twitter.com with a status id in the query string, and a few have moved to x.com. That is a small detail with a practical consequence: social post links are the weakest possible citation, since they can disappear or become inaccessible independently of the code. The screenshots do the real work here. Each is stored under the repository's own asset path with a long generated filename, which means the visual record of what each sample produced is preserved in the repository itself rather than only on the social platform. For a platform whose whole selling point is visual, that is the more durable half of the record, and it is what makes the table scannable at a glance. The README also opens with a funding appeal. The author asks for sponsorship and explains that if the source code is helpful, please support by sponsoring the repository. That framing sets the expectation honestly: this is a personal portfolio project maintained by one person, which is consistent with the forty separate directories and the daily cadence. ## What the license permits and what to expect from the code GitHub reports MIT, and there is a `LICENSE` file at the root, so the grant is unambiguous. MIT is a permissive license with no source disclosure requirement, which means you can take a sample, adapt it, and put it in a commercial application without attribution obligations beyond keeping the notice. For reference code that you intend to copy rather than import, that is exactly the right license. The repository has no releases and no version tags at all. There is nothing to install and nothing to depend on, which is consistent with the directory layout. Anyone planning to use this code is reading it rather than consuming a package, and the absence of releases means there is no stability promise to evaluate. The last push was on 2026-06-25 and the project is not archived, so it is still receiving commits. That is worth knowing because the forty days were all built around the launch period of the platform, and a repository that is still being touched may have retrofitted some of the samples to newer APIs. Check the last modification date on any particular day directory before assuming it reflects the original challenge entry. ## A follow-on project signals where the author went next Near the top of the README the author links a second repository, visionOS_2_30Days, and says they have started a new project and asks readers to take a look at it too. That single line is more informative about the trajectory than anything else in the README, because it indicates the first challenge was completed and concluded rather than abandoned. A reader deciding how to use this material should factor that in. The second repository is the continuation, which means anything the first project covered in depth is likely revisited there with more experience behind it. For a specific capability, checking whether the follow-on project has a better version of the same day is a reasonable step before copying anything. What neither project does is claim completeness. These are demonstrations of the sort of thing that can be done, built at the pace of one per day, which is a constraint that favours small focused samples over production structure. Treating a day as a starting sketch rather than a component to integrate is the difference between this repository being useful and being a trap. ## Conclusion The right way to read this repository is as forty independent reference implementations, not as one program. Each directory has its own Xcode project, so you open the day that covers the capability you need and you are not entangled with the other thirty-nine. What the repository does not offer is a walkthrough, shared abstractions, or guidance on which approach is current, so the value is entirely in the code you copy and the sequencing it gives you. Pick the day whose title matches your task, check the language and framework tags to confirm it is not an older API, and expect to rewrite rather than import. ## FAQ ### How many visionOS projects are in the visionOS 30Days repository? Forty directories, Day1 through Day40, despite the name saying thirty days. The README explains the difference by noting that the author kept submitting after the thirty day challenge, adding extra entries because there was more to cover. ### What frameworks do these visionOS samples use? The repository topics name arkit, metal, realitykit and visionos, and the language is Swift. RealityKit covers the scene graph work, ARKit covers camera-based placement, and Metal appears through shaders and textured geometry. Several days also involve SwiftUI views placed into immersive spaces. ### Does visionOS 30Days have releases or installation instructions? No. There are no releases and no tags. Each day is a standalone Xcode project that you open in the IDE, so this is reference code to read and copy rather than a package to depend on. The license is MIT, which permits copying it into your own work. ### Are the samples in this repository still current for the visionOS SDK? Each day links to the social post announcing it, which is a better signal of the date than the files themselves, and the repository has no version tags to check against. Apple has changed parts of the RealityKit and ARKit surfaces since launch, so a specific sample may need adjusting. The repository is still receiving commits, with the last push on 2026-06-25. ### How does visionOS differ from ARKit on iOS? ARKit is the framework name common to both, handling camera input, plane detection and world tracking. visionOS adds SwiftUI windows, an immersive space with no container, and Ornament for pinning a view into shared space. The samples here cover both, which is why ARKitSession placement and immersive space work both appear in the day list. ## Sources - [Issues](https://github.com/satoshi0212/visionOS_30Days/issues) - [License: MIT](https://github.com/satoshi0212/visionOS_30Days/blob/main/LICENSE) - [README](https://github.com/satoshi0212/visionOS_30Days/blob/main/README.md) - [satoshi0212/visionOS_30Days on GitHub](https://github.com/satoshi0212/visionOS_30Days) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/satoshi0212-visionos-30days