A little background. I started with computers back in the late 60's. At the end of my career I was a developer of system software for IBM mainframes written mainly in Assembly. So, I am used to small computers, 256K in my first mainframe, and tight code, we had a customer that shoved 1,000 transactions a second through one instance of our code.
With that background I came to the iPhone, for fun. I can progrram, I designed and coded for a living for years. How hard can this be?
It's an entirely different world. There were around 200 instuctions and I regularly used about 50 of them. I knew the rest existed and if I had to use them I could look in the principles of operation manual. I knew them after the 40 years I spent using them. God only knows how many classes, functions, options for those functions, etc. SwiftUI, and other old frameworks that are still used, gave but the total has to be in the thousands.
So I watched a video or two, got an idea of what I wanted the app to look like, and had nothing but problems. About 2 steps into the code I had to go off to Google, my friend, and root around until I found something that would work. Then 1 more step and back to Google. Three mre steps and back to Google where I discovered what I did back at the beginning was not how Swift/iOs did things and if I did it some other way it became much simpler. It almost made me feel like an idiot. What saved me from that was the understanding that I could do some things well and others poorly and the things I did poorly could be imprved.
So, the way I was doing things was not going to work. It would take me years of stopping constantly to find out how to do something and finding out that something I did 20 steps ago was not the way to do it and now I had to go back and do all of it again. I gave up.
Go back to the beginnign and take the course. It was tough at the beginning. I know what a variable is, I know what a pointer is, I was used to working with pointers to pointers and knowing how a structure mapped to reality and I could subvert how I accessed it. It made some thing easier. But, and this is big, doing it my way introduced bugs and places where bugs could appear when the code was updated. Realise this, you can write fresh code and know how it works and know the tricks you used to make it "better" but, I sometimes worked with code written 20 years ago, and patched and updated for the past 20 years, and I did not know what tricks the original programmer used 20 years ago, and if I changed something here then a thing I thought was unrelated way over there broke.
I got through the early days. I did not skip stuff. I learned how Swift/iOs does things. I wrote useless apps. An entire app to pick something from a list and then forget it if you restart the app. Write a string out and read it back in. Who would need that?, Pop up an alert when I press a button. God why would I do that? Then one day I was able to write stuff, for my real app, that let me pick an option from a list, I could save the data, real data from my app, and read it back in next time I ran. When my fat fingers did the wrong thing an error screen would pop up and tell me the correct thing to do. I had taken what I learned in the stupid apps and put it together to write my app.
I'm still learning. I hope I will continue always. I no longer look at Swift/iOs and thnik how can I make it work the way I think but rather look at what I want and think how can I do that with Swift/iOs.
I may not be able to do something now, but I know it can be done and how it can work, and where to find an example, and how to fit the example to my desire. I used to look at an example I found with Google and spend hours figuring out how it worked and no I can find an example and immediately know how it works.
Things have changed from "I want to do this" that Swift/iOs REALLY does not want to do to "I want this th happen" and I know, in general, how I can do it in Swift/iOs.
Thank you @twostraws.
PS I often complain about stuff. I tell myself it's good to tell someone when they screw up. However, if you do that you also need, sometimes, to point out when someone does an above average job. I try to find 1 above average for every 10 disappointments. I think this makes me a better person.
SPONSORED In-app subscriptions are a pain to implement, hard to test, and full of edge cases. RevenueCat makes it straightforward and reliable so you can get back to building your app. Oh, and it's free if your app makes less than $10k/mo.
You need to create an account or log in to reply.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.