3 ms·

Say a fund constrained startup, with single iOS developer who is experienced in Objective C. There’s no reason to go for Swift if building MVP is priority; as i

Say a fund constrained startup, with single iOS developer who is experienced in Objective C. There’s no reason to go for Swift if building MVP is priority; as it should be for any startup. If compile times are longer in Swift, it increases cost on new hardware as well. So cost plays an important role in the adoption of Swift as well.

valuearb 9y ago
Compile times, while aggravating, have dick to do with time to market. Time to find and fix bugs dominates time to compile, and the language that produces far fewer bugs (Swift) is the time to market and low cost champ.
- CodeWriter23 9y ago
  Coders produce bugs, not the language they use.
  - pjmlp 9y ago
    The language they use has high impact on how what errors they write.
CodeWriter23 9y ago
I used the same logic in implementing my latest app, that taking a 3 month or longer learning curve with Swift would delay my time to market. That turned out to be true, but then again, with 15 years of ObjC under my belt, I’m cranking out more working code than bugs, so I don’t need language features to keep me from making stupid mistakes. However, what I learned is, if you want to leverage MIT or BSD licensed widgets, libraries and etc, Swift is where it is at. Way too many of the ObjC code available has gone fallow with iOS 8 or 9, so you can still use it now. But the writing is on the walls, sooner or later iOS 12 or 15 is going to break that code and then the ObjC choice turns into technical debt. It runs the gamut from code that isn’t AutoLayout aware, to using deprecated but still available methods. I’ve steered clear of any code that hasn’t seen an update in 18 months.
3chelon 9y ago
If it's a startup knocking up an MVP, I hardly see compile times being an issue. It's only when there's a massive, usually legacy, and therefore largely Objective-C based codebase that compile times start to hurt. It shouldn't be a factor in the decision about using Swift or not.
- mattschmulen 9y ago
  When choosing a language, framework or “platform” there are only three things that matter: (1) Time to market: how fast can you implement a “ship-able” feature, app (2) Resource cost/availability: can you find delivery resources easily and cost effectively. Sometimes this resource is you, metric appropriately. (3) Scalability: as you grow and features change, how do the other two things change. Do they change for the better or the worse. The weighting of these depends on longitivtiy expectations. If your short sighted for immediate reward weigh (1) and (2) higher if your confidence is high on the outcome of what your doing then weigh (2) and (3) higher. For this discussion Swift wins on almost all fronts. The exception might be legacy maintenance , and even then it might be a knife fight of when and how.

valuearb 9y ago

Compile times, while aggravating, have dick to do with time to market. Time to find and fix bugs dominates time to compile, and the language that produces far fewer bugs (Swift) is the time to market and low cost champ.

CodeWriter23 9y ago
Coders produce bugs, not the language they use.
- pjmlp 9y ago
  The language they use has high impact on how what errors they write.

CodeWriter23 9y ago

I used the same logic in implementing my latest app, that taking a 3 month or longer learning curve with Swift would delay my time to market. That turned out to be true, but then again, with 15 years of ObjC under my belt, I’m cranking out more working code than bugs, so I don’t need language features to keep me from making stupid mistakes. However, what I learned is, if you want to leverage MIT or BSD licensed widgets, libraries and etc, Swift is where it is at. Way too many of the ObjC code available has gone fallow with iOS 8 or 9, so you can still use it now. But the writing is on the walls, sooner or later iOS 12 or 15 is going to break that code and then the ObjC choice turns into technical debt. It runs the gamut from code that isn’t AutoLayout aware, to using deprecated but still available methods. I’ve steered clear of any code that hasn’t seen an update in 18 months.

3chelon 9y ago

If it's a startup knocking up an MVP, I hardly see compile times being an issue. It's only when there's a massive, usually legacy, and therefore largely Objective-C based codebase that compile times start to hurt. It shouldn't be a factor in the decision about using Swift or not.

mattschmulen 9y ago
When choosing a language, framework or “platform” there are only three things that matter: (1) Time to market: how fast can you implement a “ship-able” feature, app (2) Resource cost/availability: can you find delivery resources easily and cost effectively. Sometimes this resource is you, metric appropriately. (3) Scalability: as you grow and features change, how do the other two things change. Do they change for the better or the worse. The weighting of these depends on longitivtiy expectations. If your short sighted for immediate reward weigh (1) and (2) higher if your confidence is high on the outcome of what your doing then weigh (2) and (3) higher. For this discussion Swift wins on almost all fronts. The exception might be legacy maintenance , and even then it might be a knife fight of when and how.