I like to call this TDS (token derangement syndrome)
606 karma · joined February 17, 2016
Congrats Astral and co!
Would love to see more Swift adoption outside Apple ecosystem because it’s truly the best language I’ve worked with; but the busted state of tooling and environment (Xcode, janky at best VSCode support) will need to be improved before it can ever escape iOS/macOS only orbit.
Getting to FSD is probably moving a lot slower than they hoped and it's looking more and more like it will be another decade (or multiple) until a self driving company can turn a dime of profit. GM doesn't strike me as a particularly innovative company so the idea of a decades long moonshot probably isn't very appealing to them.
The dragging / lying to regulators incident was bad but axing the founders / CEO seems like it would have been enough if GM were excited about the company long term.
Mobile first ones are nifty (used copilot for a bit), mainly for on the fly category updating, but after budgeting with Monarch on the web for a year and change now I don't think I can go back to a primarily app based one. Much easier to sit down once a week and crank through / review everything on web interface.
Thanks for the great work you and the Monarch team are doing, it's helped my wife and I save a lot of cash since we started using it
APIs / data models?
But IMHO for apps where that isn't the case starting with a single platform is a good bet.
Then can treat the other platform as a marketing cost - i.e. if you're making 75k on iOS and predict a similar revenue for Android it's worth it to hire an Android developer for to build it out. But if one hasn't yet found a few hundred quality users on one platform why build the other one.
You'd have the easiest native API access and fewer headaches. Once you hit PMF & have proven the idea, add the second platform.
Is there a benefit to launching on both platforms out of the gate? Unless perhaps there are specific React web assets you'd like to reuse to get up and running faster via React native.
I think it depends on what the goal of the screen is. If the goal is to simple provide information to the user, it makes sense to have clean, simple, and snappy animations.
However, I think there are also situations where the experience itself is the goal. i.e. give the user a visually pleasing graphic, animation, interaction, etc. In this case going a little wild with animations can be a good thing.
Most in app situations should be the first (snappy, clean, useful). But selectively sprinkling a few instances of the second throughout your app can bring the experience to the next level.
In our case, we wanted the rewards flow (it's a banking/brokerage app) to be a fun, gamified experience to separate us from typical banks. So we opted to add a very visual, interactive experience in this single part of the app. There's a demo video above. While it's certainly extra, I think it makes the core flow of the app a unique experience.
(shameless plug; check us out at https://www.withapollo.com we're YCS21, just launched last week, and are hiring an iOS engineer!)
A few startups ago we built our app using SwiftUI 1.0. At that time, while 90% of it was fantastic, 10% was either unworkable or extremely unreliable, causing for some maddening bugs. The documentation was laughable so for these reasons I chose to do the app for a subsequent startup in UIKit.
Fast forward to my most recent company; decided to give SwiftUI another shot (targeting iOS 14 & SwiftUI 2). I am 100% glad we did. It’s been pretty incredible; we’ve built a reasonably complex banking app at a pace not possible with UIKit. The animations in particular are crazy good to work with; we’ve got some very complex animated flows that would have taken weeks and thousands of lines with UIKit… with SwiftUI it was about 5 days.
It’s definitely not without its downsides; documentation is still slim at best, but there’s plenty of blogs and resources (https://swiftui-lab.com/ is the most helpful IMO) available now. There are also still some maddening bugs that appear in production and take a day or two of head scratching only to discover it’s a bug in the framework (most recently; using #available causes code to crash on the platform it’s protecting against lol), but there are always workarounds. Still, time wasted on these has been vastly outweighed by the weeks / months of time saved.
Finally, you can always use UIKit as an escape hatch through UIViewRepresentable.
iOS 15 is at 85% adoption, so we plan to drop support for 14 somewhat soon, which will give us an even more robust framework as well as async await APIs. Not feasible for most companies I know, but even supporting 14+ Will be pretty reasonable when iOS 16 drops in September.
Apollo (https://www.withapollo.com) is building a debit card that rewards users with stock. Users get daily cash back in fractional shares of popular stocks as well as chances to win a full share. Think point.app crossed with the Robinhood referral program.
We're a small team (3) that's YC backed (S21) and are looking to hire 1 Engineer and 1 Designer, ideally both with Mobile experience. Under the hood we're a bank and brokerage, so if you're keen for fintech it's a unique and interesting product space to build in.
Check us out on the App Store (https://apps.apple.com/us/app/apollo-banking-made-fun/id1586...).
If you're interested in chatting please reach out to me at josh {at} withapollo.com!
While I really like the concept (esp since it means I don't need to make my own workouts, which was often an excuse I used not to workout) I haven't found the accountability aspect very effective, I was at it for a few months and then dropped off, despite the daily "YOU GOT THIS!!" text from a stranger on the other side of the country.
It's entirely plausible that at the end of the day I'm just lazy/not motivated enough and no amount of accountability will be helpful, but I wonder if there's a better form of accountability, particularly through likeminded social circles, you could integrate.
Just riffing (using workout as the habit, since I will absolutely pay big $$ if something gets me to work out more, future is $150/m);
1. Social shaming
a. the app notifies a bunch of friends every time you miss a workout.
b. I pay for someone to blow up my phone / texts ad infinatum at a certain time until I'm in the gym's geofence.
2. Material loss
a. you use Plaid to pull $XX out of my account and send it to my buddy every time I miss a workout.
b. set aside some large amount of $$ like $1000 and if I don't get to the gym 20x in a month, confirmed by a third party, the money is gone forever.
3. Material gain;
a. join a group of friends; y'all put $100 in a pot, add 1 point for every workout and subtract 3 points for every miss. When the squad hits 100 points you spend the money on a trip to Fogo de Chão. If you go below 0 the money is gone forever.
b. partner with gyms & give a 40% membership discount if the person has a rolling 15 days / month attendance.
That being said, after building with Vapor I felt like there was room for a framework that focused a lot more on convention like Laravel / Rails to keep things lean and fast.
Consider ORM APIs…
In Vapor require property wrappers around each field, as well as manually entering in the table name, db column the keys map to, and needing to write an initializer.
final class Planet: Model {
// Name of the table or collection.
static let schema = "planets"
// Unique identifier for this Planet.
@ID(key: .id)
var id: UUID?
// The Planet's name.
@Field(key: "name")
var name: String
// Creates a new, empty Planet.
init() { }
// Creates a new Planet with all properties set.
init(id: UUID? = nil, name: String) {
self.id = id
self.name = name
}
}
And because it uses Swift.Codable doesn’t have to use expensive reflection APIs to decode, giving a decent performance boost (disclaimer: last time I checked).
struct Planet: Model {
var id: UUID?
var name: String
}
final class Star: Model {
@Children(for: \.$star) // 1-M
var planets: [Planet]
@Parent(key: "star_id") // M-1
var star: Star
}
struct Star: Model {
@BelongsTo var star: Star // M-1
@HasMany var planets: [Planet] // 1-M
@HasMany var moons: [Moon] // “Has Many Through”
static func mapRelations(_ mapper: RelationshipMapper<User>) {
// infers mapping from stars.id -> plants.star_id -> planets.id -> moons.planet_id
mapper.config(\.$moons).through(“planets”)
}
}
1: https://github.com/alchemy-swift/alchemy/tree/main/Docs#docs
With async/await landing last week and the leaps and bounds of the package manager over the last couple years, the ergonomics of using Swift for non-iOS work has gotten significantly better. Coupled with the built in safety and elegance of the language I think that, especially for server work, Swift is a very attractive option.
Shameless plug; for these reasons I built a Swift backend framework for fullstack iOS development[1] that we've been using it at my company while going through YC this summer.
It's been very powerful to have mobile and server in the same language and codebase and has helped us (native iOS backgrounds), move quickly.
I've considered building some tutorials for a backend framework I was working on, and it would be sweet if they were interactive.
Wondering if it would be feasible to have a server running in the one off docker containers so that people could run some simple requests on it to see how it works. It would also be sweet if it could run a simple SQLite database so users could play around with the ORM components as well.
Congrats on the launch & I'll be following this!
Does sound like there would be a lot of technical limitations to adding support in prior versions.
Interesting discussion of the behind the scenes here https://developer.apple.com/videos/play/wwdc2021/10254/
That being said, it started as geared towards iOS/macOS & even so there have been decent cross platform wins (linux compiler support is pretty solid, SPM).
I hope that as the language matures the language features that have been the priority on the roadmap (async/await, generics, memory management) will give way to more cross platform tooling.
I think sometimes people forget that Swift is still a relatively new (late 2014, ~7 years old) language. Given its scope and sizable feature set, it's no surprise there are many kinks to work through. Fortunately the team has been cruising and it gets more solid every year.
Right now it's a de facto for iOS and there's a nascent but passionate server community, give it a few more years and I think it'll be a much more attractive for things outside of iOS.
Effectively UBI but declines as the person makes money.
Some rough calculations:
In 2019 there were 34m people in poverty[1], lets assume 2 people per household (lower than nationwide average of ~3) so 17m households.
Topping each of them up to above the poverty line (~13k/y/person) would be 26k / household / year would be 442bn (and that's assuming all people below poverty line make 0 dollars).
Not bad considering the government already spends over twice that (1tr) on welfare each year[3].
Like others have said healthcare, housing issues etc would still be very damaging to some, but it's an interesting concept that could put every person in the country above the poverty line for not that much $$.
I also like that it (theoretically) still encourages working since a) poverty line is still a lower quality of life. and b) when you're below the line and make more money, the government gives you less $$ but less than you are making. i.e. if you make an extra 2 dollars, the government stopped reduces by 1, or something akin to that.
[1] https://en.wikipedia.org/wiki/Negative_income_tax
[2] https://www.census.gov/library/publications/2020/demo/p60-27...
[3] https://www.budget.senate.gov/imo/media/doc/CRS%20Report%20-...
https://johnmcwhorter.substack.com/p/is-the-elect-a-mere-col...
Been building this framework over the past year, with the goal of leveraging Swift’s speed and safety with being able to share lots of code between iOS and server. Swift on the server is still a relatively small ecosystem so the focus has been creating something clean and Swifty that can accomplish most things out of the box. Would love some feedback on the code itself or the dev experience!