This is more of an advice question, as to when it's a good idea to create your own framework, vs. when you should just reuse some classes and resource files. I've got a situation, where I've created something like 6 classes, and a number of image files that will be used in at least 4 different applications that I'm creating. Is this a good time to create my own framework?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS When to Create a Framework
- Thread starter BadWolf13
- Start date
- Sort by reaction score
Are you using any source control, like GIT? If you are, you could instead chose to make those files part of a submodule, and just use GIT to manage those files in a centralized location.
Well source/version control is rather what it sounds like. GIT (http://git-scm.com) is the default source control used by modern versions of Xcode, and I highly recommend it.
+1 for source control.
I tend to create a library when I find myself relying on a number of classes in multiple projects. Compiling the library in one place and including it + headers is cleaner than importing and shuffling the actual source files + headers between different projects as changes are made.
I tend to create a library when I find myself relying on a number of classes in multiple projects. Compiling the library in one place and including it + headers is cleaner than importing and shuffling the actual source files + headers between different projects as changes are made.
I don't see any benefit in using frameworks, so I usually avoid making my own frameworks and use git submodules instead. The main reason for this is that I can create different branches, for example if I want to use a feature that's only present in the newest OS X release, but still have apps that must run on previous versions.
This blog post from Wil Shipley about why "Frameworks are Teh Suck" might also help you make a decision on whether you want to use a framework or not. There's also a bunch of comments at the bottom about the pros and cons of making your own framework.
Either way, if your not familiar with source control, you really should take a look at it (I recommend git, but there are lot's of other good tools out there).
This blog post from Wil Shipley about why "Frameworks are Teh Suck" might also help you make a decision on whether you want to use a framework or not. There's also a bunch of comments at the bottom about the pros and cons of making your own framework.
Either way, if your not familiar with source control, you really should take a look at it (I recommend git, but there are lot's of other good tools out there).
No offense dude, but if I knew what it sounds like, I wouldn't have asked what it means. Your answer really doens't mean anything. The website for GIT doesn't help either, so I'm still left wondering what on earth source control is, and how it's a replacement/alternative to frameworks.
Maybe I should better explain what I've got here. I created an app, which I like the look/feel of. I'm going to apply the same look/feel to at least 3 other apps that I'm going to create. To do this, I plan to use about 6 abstract classes, 2 XIB files, and a dozen or so image files. Now, it's VERY unlikely that any user will have more than 1 of these programs installed, let alone running at the same time, so sharing of system resources, not important. What I do want, is to make it easier to start the new projects with all of those files already loaded, instead of asking myself if I forgot something. Call it laziness if you want.
The question being, is frameworks the way to go, or is this source control better, and if so, what is it?
Well excuse me for not having the time at 10pm to go into great detail the pros/cons of source control. Did you look around the GIT website a bit, maybe landing on this? http://git-scm.com/video/what-is-version-control
As another person has said, using submodules in GIT is probably easier and less of a hassle than creating, compiling and including a framework.
Ok, either I'm missing something here, or I'm still not explaining myself very well. That link you posted talks about making changes to a project, re-saving it, and keeping track of those changes. That's all good and well for someone who has multiple versions, but I'm not talking about anything like that. I'm talking about using the same abstract classes, image files and XIB files, over and over again, in different applications. I'm not talking about anything to do with versions, so why are you guys recommending version control?
Ok, now this is more like what I'm talking about. Does source control do that? If so, I can't find anything on that Git website that talks about creating a library, so a specific link would help.
Perhaps if you pay attention to the actual words we are using, and look for those instead ('submodule' vs 'library', ('submodule' has been used in 3 separate posts, 'library' has only been used in a post saying not to make a 'library')). http://git-scm.com/book/en/Git-Tools-Submodules
Here is the very first line of that page.
That link does explain things, but I'd still appreciate if you could make your responses with less snarky comments. If you're not willing to do that, I politely ask that you not respond to any of my questions.
Now that I understand what source control and Git are, wouldn't learning this whole new program(Git), just to use one of its features, be far more of a hassle than using the Frameworks creation process, which is native to XCode, and built right into it?
Learning how to use git doesn't take that long. And it is built into Xcode. Also, version control does give you more advantages than just submodules. You can also push your code to a server and then easily work on it from another machine or use it as a back up of your code. There are a lot more good reasons, a list is in this stackoverflow answer.
But back to the topic: If you do not want to use version control, then you probably want to use a framework and just add the framework project as dependency to the other projects (that way you always have the newest version). Just make sure you know exactly how frameworks work (like linking and install names). It will save you some trouble.
Each time you modify your code to fix a bug or extend functionality you are creating a new version of that code. (This is independent of the public version number for the application itself.)
Yeah, that does sound like a lot of functionality that I don't need, so I think I'll stick to frameworks. Thanks for the help in understanding it.