Tried the app on the iPad for the first time. I am a disappointed. I thought when I would use the default views that Apple provides the app will work out of the box. This is not really the case. A lot of elements are way too big or totally cut off. Especially the share extension is completely broken. The only thing that looks fine is the daily view.
Was able to implement a WKWebView to load Futureland stats into the native iOS app.
Also learned how to execute JavaScript inside the web frame to hide some elements.
Having some problems with the TabView at the bottom. It seems I already used all the customization Apple provides here for me. If I want to resemble Futureland web I will have to roll my own tab bar. I don't really want to do that right now as I think using the provided one will make building this thing for iPad or Mac easier.
1
It has been a constant up and down in my relationship with Xcode and SwiftUI. There are a lot of days where I really enjoy working with Xcode and on others it feels really painful. It is nice to have strict types, a built-in debugger and (kind of) good documentation that is directly embedded in the editor. There is a lot to learn about Swift and how Apple thinks just by using Xcode a lot. Sometimes I wish it would be a little bit more stable. There are times where I have to restart it or have to wait a long time to resolve some obvious Xcode bugs. Sometimes the error messages are beyond cryptic or I get no error message at all. Debugging like this is obviously frustrating but fortunately that does not happen that often anymore. I noticed that as I learn more about Swift these kind of errors do not appear that often.
Do develop natively for a device feels really different to the web tinkering I do on a daily basis. I can already see how I will be much more comfortable to ship native apps than web products. I am clearly not at that point yet, but I can see glimpses of it. I care a lot about interaction and this whole experiment showed me that with native I get the opportunity to build even better experiences. Small vibrations, smooth animations can make all the difference for me. As iOS gives me more control over the view layer this is a fun playground for me.
Found out that there are new SF Symbols I can use. Found this book icon that resembles our book icon more.
Fixed a bug that @justin reported that would crash the app after taking a photo.
Added a UISearchBar to the share extension.
Looked weird at first as the default padding of the view did not fit the horizontal padding of the list items with .listStyle(InsetGroupedListStyle()).
Was able to achieve the same padding when using:
SearchBar(text: $searchText, placeholder: "Search Journals")
.padding(.horizontal, 8)
Found a new undocumented SwiftUI modifier in the iOS 14 release notes named .fileImporter().
It enables importing of files through the files app.
This way it will be possible to upload files that are stored in iCloud, Dropbox and other apps that support it. This will also support uploading audio files right from the app.
Fixed some weird glitches on the login screen and added a subtle animation. Tried to play with .offset() as well but weirdly did not work. Wanted to have something like a soft slide effect from the bottom or something.
When the keyboard gets opened the parent VStack gets automatically moved around. Struggled with this before. In this case it does not produce problems. I am not sure how it will work on other views.
Pushed a new version to TestFlight.
Spent most of the morning working on the Daily view.
Finally got the animation with .matchedGeometryEffect() working like I wanted. It does not feel like on web but I still like it.
Also brought the little connections between the done Journals back. Now working even better than before. Basically rewrote the complete list. Getting more and more comfortable using SwiftUI and all its modifiers.
Learned a lot about transitions and animations today.
If I want to animate the transition between two elements I can use a modifier like this:
.transition(AnyTransition.scale.animation(.default))
If I want to combine transitions I can use something like this:
.transition(AnyTransition.scale.combined(with: .opacity).animation(.easeInOut(duration: 0.3)))
Additionally I learned more about the Result data type and how to work with it:
.response { response in
switch response.result {
case.success:
completionHandler(nil)
case .failure(let error):
completionHandler(error)
}
}
I notice how I slowly have a more familiar feeling with all Swift concepts.
4
Looked into how share extensions of other apps look like and was a little bit surprised about the results.
None of them is using a custom background color. I was looking into that multiple times now and could not find out how to do it. Every approach I tried did not work. I settled on using the same technique that Telegram seems to be using. (controller.overrideUserInterfaceStyle = .dark)
Many of the tested extensions (Instagram (crashing on iOS 14 beta), Day One, Are.na) use the default approach via SLComposeServiceViewController
Telegram was the only app that I tested, that actually gave the share extension some love. It is possible to quickly select contacts and send files around, like it is part of the system. Other apps like Are.na and Notion make it really inconvenient to quickly select where media should get uploaded.
Telegram and Twitter are the only extensions that are well designed for their purpose. When I look at this I feel like I am the only person who loves using share extensions. For me this is a crucial part for an app that wants to get out of the way. It is cumbersome to be forced to open an app when all I want is to quickly share media. It interrupts workflows and can cause unwanted distractions. I don't want to build an app like this.
While testing the Futureland app I noticed that I almost never open the actual app and exclusively use the share extension. Just like I do with Telegram on my phone. I wonder if I am the only person who uses my iPhone like this.
I think the share extension will be a crucial part of the Futureland app because it seems to be the only way to share audio files and media that is not stored in the photo library.
Looked more into how error handling works in Swift.
Every function that can throw hast to be prepended with a try statement.
Every function that can throw errors has to be marked with the throws statement.
I can check for different errors like this:
do {
try shop.order(itemNamed: "Black Shirt", amount: 26)
print("Ordered Black Shirts")
} catch OnlineShopError.outOfStack {
print("Not enough shirts in stock.")
}
catch OnlineShopError.invalidSelection {
print("Selection was invalid")
}
I can convert errors to optional values like
let a = try? errorThrowingFunc()
Read this article about Core Data today. Have to read more about this.
https://www.raywenderlich.com/7569-getting-started-with-core-data-tutorial
After a long fight with SwiftUI and iOS 14 I was finally able to use the new native TextEditor component instead of my custom UIKit-based one. I used really dirty tricks to display a placeholder and support infinite resizing of the input field. I don't get why this is not easier. The use-case feels super common.
Also switched my custom-made ProgressView for the new native one.
All in all the iOS 14 SwiftUI dev-tools feel way more stable than the iOS 13 ones. Before I experienced a lot of glitches and other weird bugs. This seem to be mostly resolved now. Can't wait for iOS 15.
4
Was able to get this alert thing to work in the share extension. I think it is time to start to cleaning up my code. It got really messy. Always experiencing this when learning new coding stuff.
Will upload this version so @internetvin can test it.
Seems like the share extension crashed because I called some first responder function in my custom UITextView component. That seems to cause problems when the UITextView is inside a SwiftUI ScrollView While debugging I noticed that showing the placeholder actually never really worked.
I decided to build the component from scratch and show a placeholder instead of automatically opening the keyboard. now the design needs work again but overall it got much more usable.
2
Took out some app features to make the app more stable. Uploaded the first version to TestFlight for @internetvin to test.
1
Used some cool syntactic sugar that @tmm showed me:
for (index, project) in projects.enumerated() where project.showInLog {
...
}
Got project reordering for Daily working. Syncs with Futureland.tv
As I am learning more and more about SwiftUI and iOS app development in general, I am coming to the conclusion that it currently is impossible to build a high fidelity app by only using SwiftUI for the UI layer. The SwiftUI API coverage is way too limited and immature to build anything that is more complex or customized than the projects Apple demos at WWDC. Of course it is possible to build high fidelity apps with the help of SwiftUI, but from my perspective this requires learning how to use UIKit and integrating it with SwiftUI views.
This year ist the first year after Apple first released SwiftUI. When I look at what features and APIs will be released this fall I guess that it will take another 2 to 3 years till SwiftUI is mature enough to completely rely on it. Till then new Swift developers like me have to swallow the bitter pill and learn UIKit.
I am really starting to appreciate Swift a lot. In general it feels fun and easy to learn. As I exclusively used JavaScript for the last couple years, it feels refreshing to get introduced to another and more modern language. I tried to dig into other languages like Go and Rust but could not really stick to it. In comparison to both, Swifts syntax feels more ergonomic and better designed. Since I left university I did not work with any language that enforced strict typing. As I love working with JSON and untyped objects in JavaScript, I was a little bit worried that I would hate the strict type safety in Swift. But actually they made parsing JSON and working with types a really pleasant experience. I am also a big fan of how they implemented enumerations. In combination with Xcode they are super easy to use and make the code very readable.
This time I did not deep dive into all the Swift documentation before I started to use it for my “Native Software” project. My approach has always been learning by doing. Maybe I should scroll through the Swift guide again to learn more of the languages concepts and its structures. I remember that it provides a lot of syntactic sugar, which makes programming joyful and the resulting code easy to read.
Today was not a good day for me. I tried to use the Xcode beta with iOS 14 but in the end it caused more problems than it fixed. I know have lines in my list view where before where no lines. A lot of people on Stack Overflow have the same exact problem and no one has a solution. Additionally I am not able to remove the arrows from this list view. Slowly really starts to feel that Apple made it super easy to use SwiftUI, but only if you want to build Apps like in their presentations and demos. Everything that needs a little bit of customization is a pain right now.
Xcode threw a lot of cryptic error messages that prevented me from running the canvas preview for most of my views. Hope they will fix a lot of this issues within the next betas.
Thinking of ditching iOS 14 for now and going back to the stable Xcode version with its own problems.
Was able to implement a navigation to some kind of project detail view. Seems like I am starting to hit some limits of SwiftUI now. For one thing, I did not set the whole list rows as NavigationLink. I only want to navigate when the user clicks on the projects title. Additionally I don't want to show the arrows on the right side. Currently I am not able to change any of those things. Can't find any helpful animation in the official API docs.
Added the an add project sheet like on our web version. I like how quickly I can create stuff like this. Although I don't really feel free when doing that. I think in the future I have to make little compromises when creating interfaces like this. Of course another solution would be to just work with what iOS provides for us. All animations and components feel high fidelity anyway.
1
Authentication on startup is working but looks still weird because I did not implement a loading screen yet. The log view is able to to receive updates from Futureland and supports client-side reordering of projects. I don't like how the reorder works right now, but there seems to be no other supported way of doing it with SwiftUI, right now. Will have to build something myself.
Continued to work on the daily view. Created some new store methods to fetch log data from Futureland and updated the components to use the real data. Sometimes I experienced weird bugs with Xcode itself. It was marking errors and warnings that magically disappeared after I restarted it.
After I am done with data fetching I want to look into drag and drop and animations.
Just wanted to share some quick thoughts on the new Xcode and SwiftUI updates Apple is making for its ecosystem. After I launched the Xcode beta for the first time I was really surprised how easy it now is to create multiplatform apps with the help of a little SwiftUI. I immediately was reminded of the simplicity that React or Vue bring, but with the huge difference that the code I can write here runs natively on all my favorite Apple devices. Another huge step is the new life cycle management API for SwiftUI. That means new developers and me will not have to learn UIKit to control the behavior our apps. Both of this changes make learning how to create apps for the Apple ecosystem way easier. Additionally the merging of platforms make the investment to learn how to build apps much more valuable. I think after this change we will see a lot more apps from new developers for all Apple platforms. In my opinion it was long overdue to provide developers with an abstraction that is easy to use, learn and usable for all Apple devices. I am excited to learn more.
1
Learned how to parse JSON, how to use lists, how to use system images and how to draw some shapes like a circle. I don't know how to build interfaces that are pixel precise yet. Will have to look into it as I care a lot for pixel perfection.
Next: HTTP-requests
If anyone has a quick read or library that helps me with that please send it to me.
5
Tried to dive in deep directly today. But in comparison to my normal work as a developer I felt way slower which makes things feel harder and more draining. I kind of always know what I need to know to achieve the next thing, which definitely feels way easier than learning programming from scratch.
I was able to start a new project, code my first views and figure out how to use the native date library to display the correct dates. Also copy and pasted an extension that lets me define colors in hex codes. When working on the web and with @internetvin I always prefer hex colors so this should makes things easier in the future.
I have to say that I enjoy working with VStack and HStack as it reminds me of using flex-box when on the web. Although they seem to be way easier to use it seems.
6
Did some research about react-native and SwiftUI and decided to give Xcode and SwiftUI another try.
Seems like a huge amount of work to learn all this new Swift stuff in comparison to learning react-native. But it is clear that I have to get more familiar with Xcode when I want to be able to build native features into my apps. Will have to look into react-native again as well because I want to compare which of the 2 gives me the better abstraction to build transitions and animations that feel smooth and native.
