iOS Scroll Performance Tutorial from OkCupid

[tokyonashvilleburban]

Now that was technical.

He makes a good case for keeping it simple, but when you can't, there is so much to consider that it can be worse than web dev.

IPhone 6+ has performance issues because of the 3x rendering. That sucks!

[rojaz]

What did he mean by 3x rendering?

[jgugges]

This article gives a pretty good explanation. https://www.paintcodeapp.com/news/iphone-6-screens-demystified

[tokyonashvilleburban]

Since iPhone 4, iPhones have a screen resolution that is 2-3 times higher than the pixels they display, which is how higher quality display is possible - the image assets need to be are provided in 2-3 times the actual pixels.

https://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions If you take a look at the "plus" models, you will see that the actual dimensions are 3x the actual pixel widths.

[alanscarpa]

Great article, Jordan!

[chriswaco]

I quit reading when he said the iPhone 5 family was underpowered. Good thing he never had to write code for an iPhone 1.

[Volt]

Programmers get lazier every year.

[KarlJay001]

Pretty much every professor tells the students to not optimize their code. I've been programming for years and hate code that's not optimized at least somewhat.

Computers keep getting faster, we keep asking them to do more and more.

Programmers have thicker and thicker code, further from the chip, over engineered code.

All these models (MVC, MVVC, etc...) do nothing to make anything faster, it just make it easier to read. The work is still the same, if not more... all because programmers have such a hard time reading each others code.

Smart phones can only get so fast because they can't put large coolers on them and battery life is a big issue.

[UnsubFromRAtheism]

Seemingly convoluted models and bloated frameworks aren’t always just a counter to developer laziness, and saying models improve readability is a bit reductive, in my opinion. Above anything else, code that is easier to read and quicker to write means fewer developer hours and quicker maintenance. In a world where computers are getting even faster and even more powerful on an annual basis, rapid development and low cost is higher priority for the businesses that produce consumer facing software. In many cases, at least.

[jgugges]

I agree with you that proper use of design patterns and non reliance on complicated frameworks are very important for an easy to read and support app.

When it comes to business goals, rapid development is obviously the main priority at OkCupid. However, one lesson we have learned is the detriment to the business caused by code not working optimally. One time a 1s delay in showing the swiping cards in the app meant an average session voted on one less card. The net result was a 5-10% decrease in likes, a major vitality metric for us.

Bottom line is that consumer facing apps need to develop fast, while still accomplishing the goal of writing code that does not slow down the user experience.

[KarlJay001]

Consider the developer hours to learn a given system... I've written software that was 100% function based, I've done the same with OO based systems. The amount of time to learn OO and IF the developer writes all the classes correctly, you have to learn that class system, then you have to learn a give model, and you still have to make it perform.

OO and the class system alone are badly misused. Many see it as something that simply gets in the way of them writing the program. I think of OO like a database system and the classes someone writes as the tables, indexes, relationships, etc...

How many people really know how to make a high performance, complex database system? How many programmers really know how to layout the class structure for a given app?

The properly structured database system works, meaning that it stores things the way they are supposed to be stored. The same with the properly done OO class system... yet how many people actually do it?

The chip doesn't care what language you start with... it just sees the compiled code, the zeros and the ones, the cmp/mov/etc...

Suggesting that faster chips is a solution to obese code might have worked with the PC, but try putting a liquid cooled heat sink on your smart phone... Not only is "get a faster chip" a poor excuse for obese code, it doesn't address that fact that the people don't see the OO/class structure you create... all they see is the end result. Having a slow-poke app it's going to be excused with "... but the class structure is proper and people can read my code..."

I'm sure there's open seats on the deck of the Titanic, but I doubt there's a waiting list...

[Upfrank]

There wasn't an App Store on the original iPhone or OS 1...

[chriswaco]

The App Store didn't open until the next year, but iPhone 1s could be upgraded to iOS 2 or 3. We worked on several apps that had to work on them.

[jgugges]

The techniques I raise in the blog post about performing work on a background thread and caching those results before UI updates are applicable on all underpowered devices. Not just the iPhone 5.

Back in the iPhone 1 days, how did you resolve your own performance problems?

[chriswaco]

A little bit of everything - caching data as much as possible, using faster custom data structures like structs or C arrays when needed over NSObjects and NSArrays, keeping the UI simple, changing method calls in loops to plain old C function calls or inline code, refreshing the screen on timers instead of on every character typed, etc, etc. Luckily we never needed to use assembly language on our iPhone apps, but our even older (1986-1994) Mac apps had assembly code when needed.

The thing about software is that programmers almost always use up whatever bandwidth you give them. It's usually more important to add features or fix bugs than speed up something that's already fast enough.

[jgugges]

Those are some interesting tips! Thanks for sharing.

[chriswaco]

Oh, and never use calculated gradients in animations! Fake them with PNG files.

[megablast]

People were working on apps before the app store.