keep it simple. Frameworks?

keep it simple

Recently I had a project in a workspace to produce a framework of Objective-C and Swift code – supplied by someone else. I had a devil of a time getting it to build for me. And when I did, I tried to copy it into my own project to use it – to find out somehow the project thought I already had it. So I had to link to it. Which meant building an archive didn’t work, so I added a path for embedded frameworks, and then found out there was a problem with how the framework was built in the first place. I was jumping through hoops. I’m no Xcode guru. It’s great until it doesn’t do what you want.

I spent hours trying to get things to work. Hours. The dry-heaving Xcode project red sweats. The kind you want to roll a d20 saving throw to see if it will make it to the end of the day and live on.

I took the framework project code, copied it to my swift project. Added a bridging header for an Objective-C header, and I was done. In the span of about (really) 10 minutes I could have saved myself hours. Now… if that framework changes I need to stay on top of that. If I used a linked framework under source control, I’d be better. But that framework won’t really change much at all.

Sometimes it really is better to keep it simple.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.