Posts Tagged iPhone

Release iPhone/iPod Touch FreeSWITCH Console

fs_logo_57_57 Well, it has been a long battle.  Fought since June 5th, 2009, but at long last Apple has come through and allowed the FreeSWITCH Console application into the app store.

FreeSWITCH is an open source telephony platform designed to facilitate the creation of voice and chat driven products scaling from a soft-phone up to a soft-switch.  It can be used as a simple switching engine, a PBX, a media gateway or a media server to host IVR applications using simple scripts or XML to control the callflow.

So without much further ado, here is the iTunes link: App Store, FreeSWITCH Console.

FreeSWITCH Console Screenshot

The application requires that you have the event socket layer (ESL) module installed in your FreeSWITCH instance.

, , , , ,


Apple App Store Scalability Issues and Subjective Rejections

I found a wonderful article by Craig Hockenberry regarding Apple’s big iPhone and App Store issue. This link says it all regarding the issues with Apple’s inability to keep developers happy. Whenever I think back to what put Microsoft atop the operating system market, the first thing that comes to mind is Microsoft’s support of the developers. Though many developers agree that the documentation for the Windows API isn’t all that great, it is there and Microsoft does support it. Also, Microsoft allows us to write what we want without any requirement to run our code through a quality control structure. Granted, this is perhaps the reason why there are so many viruses (and junk) written on Windows, but this has also allowed developers to freely create innovative programs that enable Microsoft to still take a big piece of the operating system market.

Now having a quality control system in place such as Apple’s iPhone reviewers is a great idea because it prevents malware from getting on your phone. No one refutes that. But as soon as you get wrapped into what and how they are reviewing, you quickly find out that the process is a self-defeating one covered with a thick layer of subjective decision making. Take for instance a FreeSWITCH Console application I wrote a few months back. The application merely does asynchronous socket communication with an open source FreeSWITCH server instance that has the “event socket layer” module installed. It’s a clean pass-through client, built for developers that does nothing more than relay commands that you, the developer, must know. I submitted the application for review on June 5, 2009. They just got around to finally responding on July 26, 2009. What is with this horrible delay? It speaks clearly that there is a lack of scalability in the Apple reviewer model. Here is an email I received from the reviewing staff the other day.

Hello Chris,

Thank you for your emails and the clarifications. The account you provided and the instructions you gave do show the application as functional. However, since the application allows users to connect to any FreeSWITCH server, we need to be able to review all features that a FreeSWITCH server can implement, which include functions such as SIP and PBX.

Please respond to this email with the necessary information, and please upload a new binary to iTunes Connect.

iPhone Developer Program

Let me explain this further. They are asking me to provide them with a SIP/PBX account so that they can go beyond testing my application and begin testing the FreeSWITCH server! If you’ve ever delved into the FreeSWITCH server code itself, you know that it is a well written and scalable telephony application that is incredibly complex. I just want my app in the app store so that other developers can enjoy using their iPhones and iPod Touches to control their developer instances of FreeSWITCH! So why all the trouble, Apple?

As you can see, this has gone well and beyond testing for malware. This is a reviewer subjectively deciding to test a really cool FreeSWITCH server. Now, I have no trouble with that, just don’t do it on my dime. I’ll be re-posting the FreeSWITCH application into the iTunes Connect system in about 3 weeks when my blood has stopped boiling.

I have another application (which will remain unnamed for the time being) that I’m trying to get into the App Store as well. First off, I am planning on charging for this one in the Tier 1 model which basically equates to the customer paying $.99. I posted this app on the store 6 days ago. Last night, I received the infamous “taking unexpected additional time for review” email. Two hours later, I received the Section 3.3.14 death sentence response::

Dear Mr. Danielson,

Thank you for submitting ‘Removed App Name’ to the App Store. We’ve reviewed ‘Removed App Name’ and determined that we cannot post this version of your iPhone application to the App Store because it contains objectionable content and is in violation of Section 3.3.14 from the the iPhone Developer Program License Agreement which states:

“Applications may be rejected if they contain content or materials of any kind (text, graphics, images, photographs, sounds, etc.) that in Apple’s reasonable judgement may be found objectionable, for example, materials that may be considered obscene, pornographic, or defamatory.”

If you believe that you can make the necessary changes so that ‘Removed App Name’ does not violate the iPhone Developer Program License Agreement, we encourage you to do so and resubmit it for review.

iPhone Developer Program

Wow. My application truly pales in comparison to the likes of Easy-E, Cannibal Corpse, Geto Boys, and any R-rated movies Apple already sells on iTunes, let alone the other similarly themed apps that are already available. We’re hoping it was our bad luck that we had a reviewer with a dulled sense of humor… anyway we’re now attempting to get it posted into the App Store with some minor revisions.

I’ve really digressed a bit in this blog, but my basic point is that Apple’s App Store Reviewing squad is uncoordinated in their decision making skills. I’ve read online that people with the 3.3.14 issue have only to change their description text and successfully re-submit. If this is the case, then we truly do know that Apple is fraught with subjectivity and developer’s livelihoods are being toyed with. Why not take the high road Apple? Allow applications into the store by merely testing for any sort of malware, and using your already-existing rating system for content. Leave the ultimate purchase decision up to the consumer. Heck, you can hire my company MaxPowerSoft and we’ll even write the grep scripts to automate the red-flagging for any submitted applications. Just don’t cut out your developers – they could be your lifeblood.

Special thanks to my brother Nic Danielson for reviewing and editing this post.

, , , ,


iPhone Network Connectivity Test Example

Every iPhone developer that has integrated a network connection based application has had to follow the Apple HID (Human Interface Design) rules. This means, that in order to get the Apple reviewers to sign-off on your application, you have to pass the network connectivity test. Basically, in the case of a catastrophic network disconnect issue with 3G and WiFi does your application properly alert the user that it will not perform properly without the usage of the network? I’ve seen a lot of workaround techniques where users attempt to do an HTTP GET on say Google or some other website. Clearly, this kind of technique will work sporadically in an unknown environment common to the mobile device. I mean, imagine causing your application users to sit through a 5-30 second web request timeout. The end-user will probably believe that the application is hung. The ideal solution happens to be handed to us in the API Framework SCNetworkReachability. (Make sure your codebase is linked properly with the “SystemConfiguration” Framework).
It’s worked for me and I recommend it for doing a simple network connectivity test.

#import <sys/socket.h>
#import <netinet/in.h>
#import <arpa/inet.h>
#import <netdb.h>
#import <SystemConfiguration/SCNetworkReachability.h>
//Snip, you know we're in the implementation...
- (BOOL) connectedToNetwork
	// Create zero addy
	struct sockaddr_in zeroAddress;
	bzero(&zeroAddress, sizeof(zeroAddress));
	zeroAddress.sin_len = sizeof(zeroAddress);
	zeroAddress.sin_family = AF_INET;
	// Recover reachability flags
	SCNetworkReachabilityRef defaultRouteReachability = SCNetworkReachabilityCreateWithAddress(NULL, (struct sockaddr *)&zeroAddress);
	SCNetworkReachabilityFlags flags;
	BOOL didRetrieveFlags = SCNetworkReachabilityGetFlags(defaultRouteReachability, &flags);
	if (!didRetrieveFlags)
		return NO;
	BOOL isReachable = flags & kSCNetworkFlagsReachable;
	BOOL needsConnection = flags & kSCNetworkFlagsConnectionRequired;
	return (isReachable && !needsConnection) ? YES : NO;
//call like:
-(void) start {
	if (![self connectedToNetwork]) {
                UIAlertView *alert = [[UIAlertView alloc] 
                         initWithTitle:@"Network Connection Error" 
                         message:@"You need to be connected to the internet to use this feature." 
                         delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
		[alert show];
		[alert release];
        } else {
             //do something 

This code can also be found on this forum post.

, , , ,


iPhone (SIGBUS) Issue

If you’ve ever done any iPhone development, you’ve probably had an accident with the (nonatomic, retain) methods. These methods are difficult to use in the case where you’re working with multiple threads. Our application does not do this, but we do utilize the OpenGL ES 1.1 framework. Have a look at the following console log from the other night when my brother was beta testing our application with some friends at a bar.

Process:         myExampleApp [800]
Path:            /var/mobile/Applications/5D234CF0-1234-4E2F-9A7F-14175F39A0B6/
Identifier:      myExampleApp
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]
Date/Time:       2009-07-19 23:20:40.285 -0700
OS Version:      iPhone OS 3.0 (7A341)
Report Version:  104
Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000008
Crashed Thread:  0
Thread 0 Crashed:
0   libobjc.A.dylib                   0x30011940 objc_msgSend + 20
1   libobjc.A.dylib                   0x3001313c objc_setProperty + 160
2   myExampleApp                          0x000126e6 -[GameUIView setBasicObj:] (GameUIView.m:36)
3   myExampleApp                          0x0000f694 -[GameUIView setupView] (GameUIView.m:404)
4   myExampleApp                          0x0000ec42 -[GameUIView start] (GameUIView.m:173)
5   myExampleApp                          0x00002816 -[CoreViewController playGame] (CoreViewController.m:79)
6   myExampleApp                          0x00005e80 -[SplashGLUIView touchesEnded:withEvent:] (SplashGLUIView.m:606)
7   UIKit                             0x309a60d4 -[UIWindow _sendTouchesForEvent:] + 520
8   UIKit                             0x309a5464 -[UIWindow sendEvent:] + 108
9   UIKit                             0x30936e3c -[UIApplication sendEvent:] + 400
10  UIKit                             0x30936874 _UIApplicationHandleEvent + 4336
11  GraphicsServices                  0x32046964 PurpleEventCallback + 1028
12  CoreFoundation                    0x30254a70 CFRunLoopRunSpecific + 2296
13  CoreFoundation                    0x30254164 CFRunLoopRunInMode + 44
14  GraphicsServices                  0x3204529c GSEventRunModal + 188
15  UIKit                             0x308f0374 -[UIApplication _run] + 552
16  UIKit                             0x308eea8c UIApplicationMain + 960
17  myExampleApp                          0x000020b6 main (main.m:14)
18  myExampleApp                          0x0000202c start + 44

The core method here that is the issue is implemented as:

//in the .h file.  
@property (nonatomic, retain) NSObject *basicObj;
//in the .m file.
@synthesize basicObj;
- (void)setupView
   if (self.basicObj != nil) {
		[self.basicObj release];
		self.basicObj = nil; //line 404, this is where the error is located.

As you can see, the issue appears to be based on how we access the basicObj object. The definition of a SIGBUS error, is pretty straight forward. We are generically having some sort of memory issue.

As of this writing, I’m still doing extensive testing and I’ll update this post if I find a better solution. Here is what I’ve found to work. I’m beginning to wonder if there is a funny timing issue with the “release” methodology. I’ll make sure to post back here if I find there to still be an issue or I find a better solution. Comments are appreciated.

- (void)setupView
   if (self.basicObj != nil) {
		[basicObj release];
		basicObj = nil;

, , ,