Just a thought, does it have to be Obj-C? I mean the iphone app store opened for some other languages, I don't see why this one can't.The app stores are native to Obj-C, that is Apple's main language.
I hatehatehate Objective C. Really... this isn't just my rebellion complex speaking here, I think it's syntactically ugly and confusing as hell.That's so strange. You're repulsed by it and I find it beautiful and elegant. To me it is so much easier than any other language I've ever used. Even better than Sc, Java, Vb.net, and Haskell.
Mike's CommentYou can sit in front of a book full of latin words and try to write "Mary Had a Little Lamb" in Latin though you aren't gonna get anywhere. You need a coherent dictionary. Sadly Apple's docs were made for the people in the know. They are incomprehensible to normal human beings. If you want to look you gotta google for beginner friendly tutorials and examples that do what you want to do. Then you study that code, experiment and try to replicate the success. Eventually you'll start understanding and connecting the dots.
I agree with Mike on this one.Yeah you are right. RB certainly is much more learner friendly. Xcode expects you to understand. Though Xcode's power exceeds RB's. There are trade offs though in the long run Obj-C is a great language to learn.
Objective C is too much to deal with. RB is simple and cross platform. Tick a box for Windows and you're reaching a wider audience (although it's generally better to design the interfaces separately, at least that's what I learned after MemoNet which bombed because it looked and acted like a PC application).
Thing *myThing = [Thing new]; Thing myThing = new Thing();I <3 those brackets.
To you they look useless. Once you get into it you realize what they're actually for and you realize that they work miracles.
Yeah you are right. RB certainly is much more learner friendly. Xcode expects you to understand. Though Xcode's power exceeds RB's. There are trade offs though in the long run Obj-C is a great language to learn.
Seriously man, there's a fine line between showing off and genuinely wanting to help people.I'm just kinda excited. :)
I tried using Xcode to make a simple program to help me write better stories. Simple stuff like calculating average word length and highlighting long and short sentences. I couldn't figure it out, though. The code looks very confusing.It is quite hard to just learn by playing with it. If you Googled for some tutorials it'd help immensely.
The upside to Xcode is the easy to use interface builder. So I do have a nice interface with clickable buttons, but they don't do anything (except for a rest button, that one actually works).
Yeah, RB's more learner friendly and because of that, more powerful that Objective C. If a class doesn't exist on RB, you can make it. It's a system that allows you to write in parts of the language if it doesn't exist.Learner friendly doesn't necessarily mean it's more powerful. It can be spread to a larger crowd though the performance isn't as powerful.
The problem with Xcode is the elitist crap that comes with it. Somehow, by using RB, we're "lesser developers". How? Because we're not using Apple's SDK? I'm still making software for a platform which has less available software than Windows, so why is there a problem?Obj-C is a lower level programming language. It's a tiny step above C. C is right above machine code. I think machine code is the base. RB is kinda slow and clunky. It's like a programming language on a programming language. It layers it's runtime over different languages which allows portability but decreases performance significantly.
Obj-C works similarly. You can create classes and such.
Obj-C is a lower level programming language. It's a tiny step above C. C is right above machine code. I think machine code is the base. RB is kinda slow and clunky. It's like a programming language on a programming language. It layers it's runtime over different languages which allows portability but decreases performance significantly.
Programmers who program in RB aren't any lesser. They just aren't making programs as high performance as natively made programs. Such as C#, C, and Obj-C programmers.
I do. I shall. I will.Sorry I took longer than 30 minutes but...
Give me 30 min.
-(void)awakeFromNib {
}
- (void) timerTick: (NSTimer *) gameTimer {
[self setNeedsDisplay:YES];
}
- (void)mouseDragged:(NSEvent*)theEvent{
//CGPoint aMousePoint = CGPointMake([self convertPoint:[theEvent locationInWindow] fromView:nil].x, [self convertPoint:[theEvent locationInWindow] fromView:nil].y);
[self setNeedsDisplay:YES];
}
- (void)mouseUp:(NSEvent*)theEvent{
//CGPoint aMousePoint = CGPointMake([self convertPoint:[theEvent locationInWindow] fromView:nil].x, [self convertPoint:[theEvent locationInWindow] fromView:nil].y);
[self setNeedsDisplay:YES];
}
- (void)keyDown:(NSEvent*)theEvent{
unichar aKey = [[theEvent charactersIgnoringModifiers] characterAtIndex:0];
if (aKey == NSUpArrowFunctionKey) {
}
if (aKey == NSDownArrowFunctionKey) {
}
if (aKey == NSLeftArrowFunctionKey) {
}
if (aKey == NSRightArrowFunctionKey) {
}
}
- (void)keyUp:(NSEvent*)theEvent{
unichar aKey = [[theEvent charactersIgnoringModifiers] characterAtIndex:0];
if (aKey == NSUpArrowFunctionKey) {
}
if (aKey == NSDownArrowFunctionKey) {
}
if (aKey == NSLeftArrowFunctionKey) {
}
if (aKey == NSRightArrowFunctionKey) {
}
}
- (BOOL)isFlipped{
return YES;
}
- (BOOL)acceptsFirstResponder {
return YES;
}
- (void)drawRect:(NSRect)dirtyRect {
// Drawing code here.
}
-(void) dealloc {
[super dealloc];
}What? RB programs run, they're carbon so they're backward compatible with everything since OS 9, they're fast, they're easy to make, they can be as powerful or resource-wasting as you like so what does it matter?You're confused Tel. RB programs are just like normal programs. Though they're built using old carbon or still buggy cocoa libraries. Besides that RB sets a layer on top of the program. That layer allows RB to be in essence its own language. Though the layer also causes a decrease in performance. Anything made in Rb won't be as fast as Obj-C just for that reason.
Xcode is the next best thing since sliced bread and I'm going to swear an oath to Apple under a picture of the Queen.Xcode isn't the next best thing since sliced bread but it is useful. It gets the job done and even though it requires a large learning curve the results are fantastic.
That layer deals with the GUI and letting it interact with the OS.The layer still causes a slowdown.
Just because Carbon is old doesn't make it worse than Cocoa. Carbon is far superior in its flexibility and Apple are stupid deprecating it.
EDIT - I assumed that RB was interpreted, I'm actually interested in how that works now.I've always thought it was interpreted as well.
2.1Check out 2.14 and 2.5.
Apps that crash will be rejected
2.2
Apps that exhibit bugs will be rejected
2.3
Apps that do not perform as advertised by the developer will be rejected
2.4
Apps that include undocumented or hidden features inconsistent with the description of the app will be rejected
2.5
Apps that use non-public APIs will be rejected
2.6
Apps that are “beta”, “demo”, “trial”, or “test” versions will be rejected
2.7
Apps that duplicate apps already in the App Store may be rejected, particularly if there are many of them
2.8
Apps that are not very useful or do not provide any lasting entertainment value may be rejected
2.9
Apps that are primarily marketing materials or advertisements will be rejected
2.10
Apps that are intended to provide trick or fake functionality that are not clearly marked as such will be rejected
2.11
Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected
2.12
Apps that provide incorrect diagnostic or other inaccurate device data will be rejected
2.13
Developers “spamming” the App Store with many versions of similar apps will be removed from the Mac Developer Program
2.14
Apps must be packaged and submitted using Apple’s packaging technologies included in Xcode – no third party installers allowed
2.15
Apps must be self-contained, single application installation bundles, and cannot install code or resources in shared locations
2.16
Apps that download or install additional code or resources to add functionality or change their primary purpose will be rejected
2.17
Apps that download other standalone apps will be rejected
2.18
Apps that install kexts will be rejected
2.19
Apps that require license keys or implement their own copy protection will be rejected
2.20
Apps that present a license screen at launch will be rejected
2.21
Apps may not use update mechanisms outside of the App Store
2.22
Apps must contain all language support in a single app bundle (single binary multiple language)
2.23
Apps that spawn processes that continue to run after a user has quit the app without user consent will be rejected
2.24
Apps that use deprecated or optionally installed technologies (e.g., Java, Rosetta) will be rejected
2.25
Apps that do not run on the currently shipping OS will be rejected
2.26
Apps that are set to auto-launch or to have other code automatically run at startup or login without user consent will be rejected
2.27
Apps that request escalation to root privileges or use setuid attributes will be rejected
2.28
Apps that add their icons to the Dock or leave short cuts on the user desktop will be rejected
2.29
Apps that do not use the appropriate Mac OS X APIs for modifying user data stored by other apps (e.g bookmarks, Address Book or Calendar entries) will be rejected
2.30
Apps that do not comply with the Mac OS X File System documentation will be rejected
3. Metadata (name, descriptions, ratings, rankings, etc)
3.1
Apps with metadata that mentions the name of any other computer platform will be rejected
3.2
Apps with placeholder text will be rejected
3.3
Apps with descriptions not relevant to the application content and functionality will be rejected
3.4
App names in iTunes Connect and as displayed on Mac OS X should be the same, so as not to cause confusion
3.5
All app icons should be similar, so as to not to cause confusion
3.6
Apps with app icons and screenshots that do not adhere to the 4+ age rating will be rejected
3.7
Apps with Category and Genre selections that are not appropriate for the app content will be rejected
3.8
Developers are responsible for assigning appropriate ratings to their apps. Inappropriate ratings may be changed by Apple
3.9
Developers are responsible for assigning appropriate keywords for their apps. Inappropriate keywords may be changed/deleted by Apple.
3.0
Developers who attempt to manipulate or cheat the user reviews or chart ranking in the App Store with fake or paid reviews, or any other inappropriate methods will be removed from the Mac Developer Program
reading between the lines.Sometimes that actual meaning is in the text.
Sorry I took longer than 30 minutes but...Video's back up. In 2 parts.
Scratch Game Making Obj-C Tutorial Part 1 (http://www.youtube.com/watch?v=0-bqDsPwh7o)
Scratch Game Making Obj-C Tutorial Part 2 (http://www.youtube.com/watch?v=V6VrnI63I5o)
Source (http://cl.ly/e7aa5ab603d04f9d8645)
-Gan
Apps that encourage excessive consumption of alcohol or illegal substances, or encourage minors to consume alcohol or smoke cigarettes, will be rejected.That does it. Installing Ubuntu.
P.S. No more complaining about these rules and the Mac App Store. There's nothing we can do about it and complaining gets in the way of making progress.Yes sir, polish your shoes sir?
There is no way Apple would allow a development tool, no matter what it's programmed in.Why wouldn't they? It doesn't break any of the regulations.
You could potentially make a program with it that would.I doubt that'd be much of an issue. A user making a program in Sc that destroys their own computer.... Doesn't sound plausible.
I doubt that'd be much of an issue. A user making a program in Sc that destroys their own computer.... Doesn't sound plausible.
I think it'd have a good chance of getting through.
The whole point is that it shouldn't have to get through anything. We have a free and open platform with the Mac OS - why the hell would anyone consent to it being closed down like iOS?
Mike, its not closed down. We can still download whatever we want.
The Mac App store is basically the equivalent of a flash games website.
We can still download whatever we want.
-(void)awakeFromNib {
}
- (void) timerTick: (NSTimer *) gameTimer {
[self setNeedsDisplay:YES];
}
- (void)mouseDragged:(NSEvent*)theEvent{
//CGPoint aMousePoint = CGPointMake([self convertPoint:[theEvent locationInWindow] fromView:nil].x, [self convertPoint:[theEvent locationInWindow] fromView:nil].y);
[self setNeedsDisplay:YES];
}
- (void)mouseUp:(NSEvent*)theEvent{
//CGPoint aMousePoint = CGPointMake([self convertPoint:[theEvent locationInWindow] fromView:nil].x, [self convertPoint:[theEvent locationInWindow] fromView:nil].y);
[self setNeedsDisplay:YES];
}
- (void)keyDown:(NSEvent*)theEvent{
unichar aKey = [[theEvent charactersIgnoringModifiers] characterAtIndex:0];
if (aKey == NSUpArrowFunctionKey) {
}
if (aKey == NSDownArrowFunctionKey) {
}
if (aKey == NSLeftArrowFunctionKey) {
}
if (aKey == NSRightArrowFunctionKey) {
}
}
- (void)keyUp:(NSEvent*)theEvent{
unichar aKey = [[theEvent charactersIgnoringModifiers] characterAtIndex:0];
if (aKey == NSUpArrowFunctionKey) {
}
if (aKey == NSDownArrowFunctionKey) {
}
if (aKey == NSLeftArrowFunctionKey) {
}
if (aKey == NSRightArrowFunctionKey) {
}
}
- (BOOL)isFlipped{
return YES;
}
- (BOOL)acceptsFirstResponder {
return YES;
}
- (void)drawRect:(NSRect)dirtyRect {
// Drawing code here.
}
-(void) dealloc {
[super dealloc];
}I would love to see Sc as one of them. The only roadblock would be converting Sc to Obj-C so it could get on the app store.
It's not that Apple won't, it's that they can't.
I'm not converting it. If Apple won't take REALbasic programs in the store, then they can rot.
You've just killed any chance of a moderate and reasonable discussion.I'm sorry you feel this way.
Apple can't take anything but Xcode made products cause anything not made by Xcode can't be analyzed. If Apple took any product from anywhere there'd be pirated games, applications that steal user data and other harmful products.
get a lifeOk.
You guys are so predictable.Yeah.
they only care about where the money comes fromApple's sitting on 50 billion and have barely touched it. They literally have no need for money.
It makes me sick that they would even consider imposing rules on what is going to be the primary distribution channel for - let's face it - 50% of all Mac software.They have no choice. If anything could get in the Mac App Store it would be unreliable and anyone who downloaded anything destructive or privacy violating could sue.
read between the lines.Sometimes the meaning is in the text.
Whatever happened to the Think Different company... sighIt's still there and making new stuff. Seriously, a dedicated App Store that'll be on every Mac. This is definitely a first of it's kind for a computer platform. (Just wait till windows copies it)
Seriously, a dedicated App Store that'll be on every Mac. This is definitely a first of it's kind for a computer platform. (Just wait till windows copies it)
Sometimes the meaning is in the text.
They have no choice. If anything could get in the Mac App Store it would be unreliable and anyone who downloaded anything destructive or privacy violating could sue.
Apple's sitting on 50 billion and have barely touched it. They literally have no need for money.
Obviously, they're not going to accept applications which are likely to cease working in an OS version or two. That's not good for the consumer. I like to think of that, the "no private APIs" rule, etc. as a partnership between you and Apple -- you agree not to do a few things, and in return, they agree to do their very best to keep your app working across OS updates.
Re: Java, what they are prohibiting is not "using Java", but "relying on the presence of Java-the-optional-install". If you can embed a JRE in your application, or use GCJ, Alchemo or similar to produce a native executable, you would appear to be in the clear...
Given an OS with a command prompt, interpreters for endless scripting languages, free and open-source development tools, etc. I can't really envisage a future where the App Store is the *only* way to get applications. That would require locking down the OS in ways that consumers wouldn't accept (and that would make the OS useless to a significant number of the users, Apple internally not least).
I *can* envisage it being the only way to reach 90+% of users. But then again, currently you have *no* way to reach most of those users. They surf Facebook, write emails, make their iMovies and sort their iPhotos. Soon they'll be buying apps too.
Disclaimer: I work for Apple, but do not speak for them. These opinions are my own.
You guys are a bunch of whining babies. Programming isn't supposed to be easy. It's supposed to be powerful and flexible. You guys seem so afraid of a new challenge that can be EXTREMELY profitable.
Don't knock Obj-C just because you aren't intelligent enough to learn it.
What the hell? Programming is supposed to be hard? That's elitist bull.Programming is hard. It takes effort and hard work. At least for me it does...
Not everyone programs for profit.Profit just means a gain in something.
The point is that just because something is more difficult does not make it better.True.
- (void)drawImage:(Image*)image AtPoint:(CGPoint)pointMy dad had to use Assembly all the time back in the days of Kobalt, Fortran and... well... Assembly. It's way too time consuming to be practical. It's a nightmare to do anything you could do simply in anything else.
I wouldn't build apps in assembly for efficiency anymore than I'd build a TV for efficiency.
Well if that's what drives you, let nobody stand in your way. :)
Just don't expect to finish your first app before you're 70! ;D Hehehe...
Verse 1
C / F C / Am C / F G / G7
How many codes must a man note down, before you can call him a man?
C / F C / Am C / F G / G7
How many C's must a programmer learn, before he can truly program?
C / F C / Am C / F G / G
How many times must a group project fail, before we stick to the plan?
Verse 2
C / F C / Am C / F G / G7
How many years must a Mac fan exist, before he converts to PC?
C / F C / Am C / F G / G7
How many tears must that man then resist, before he goes crazy?
C / F C / Am C / F G / G
How many times can we just turn our heads, and pretend that we're fair referees?
Verse 3
C / F C / Am C / F G / G7
How many times must a man look it up, before the command's memorized?
C / F C / Am C / F G / G7
How many fears must that one man have, before he can see through the lies?
C / F C / Am C / F G / G
How many times must the Mac win out, before we accept that they're right?
Chorus
F / G C / E7 / Am
The answer my friend, is don't ask Silverwind.
F / G C
The answer is don't ask Silverwind.
The answer my friend, is don't ask Silverwind.lol