Would you be able to give any examples, aside from being "native" (which I'm assuming means its built on AppKit+Cocoa) as to what your app does differently or better than Charles? I use Charles pretty frequently but my co workers haven't gotten on board yet.
As an aside, IMO claiming that Charles isn't native is a little disingenuous. Yes it's built with Java, but I wouldn't dismiss it as non-native (unless you're using native in the purest of ways, meaning that its "natural" - e.g. Cocoa - to the system). I consider tools like Eclipse and IntelliJ "native" even though their UI may be poor compared to Xcode.
I think it's perfectly reasonable to describe Charles as "non-native".
For example, it doesn't integrate with Keychain, for SSL certificates, so you have to do a bunch of jiggery pokery with the openssl command if you want to generate your own CA for use with SSL interception.
For a more trivial but still annoying example, control-A and control-E don't work in Charles's text fields. In normal Mac apps, this goes to the beginning/end of the line, but in Charles it does nothing.
"Native" isn't about "poor" UI per se, but rather about whether or not it has the basic UI features provided by the system. In a native app, you have to go out of your way to disable stuff like ^A/^E because the system gives that to you by default.
I'm not a purist and will happily use non-native apps like Charles if they get the job done, but it's still a legitimate point against it.
Good questions. While Charles and other proxies are doing a fine job our dev team is also frustrated by the way they integrate with OS X. This is what we mean by native experience.
The application is in effect a single binary and makes use of various Apple frameworks which are optimised to run flawlessly on apple hardware. Only one platform is supported which means that there is less chance for bugs and platform-specific oddities. Proxy.app works as a sandbox application on OS X, distributed by Mac App Store and makes use of other native components like Keychain, etc.
Under the hood the tool is only making use of Apple frameworks. We believe that in the long term this will provide more stability and performance enhancements. Right now it takes just a moment to launch the application and there is zero friction when switching between different project files. We believe that it just works in the same way OS X applications are supposed to work and this in effect makes Proxy.app more pleasant to use.
I'll vouch for this. I've used Charles extensively, and while I haven't used Proxy yet, the most annoying things about Charles are always related to it not using proper UI paradigms, components, etc. I'd love something that was a proper Mac app for this.
As for the comparison with Burp, I have much less experience with Burp, but the pro version has a huge amount of functionality. Things like plotting the distribution of cookies so you can see if they are backed by a good RNG. It doesn't look like this is quite that advanced yet, but those are the sorts of features that only real pen-testers would be using. For most developers who just need to test stuff, this looks excellent, I really look forward to trying it out.
Some tools are much more useful in the browser - and not in the proxy. As for the session management security - you will rarely need this functionality these days unless you do security research. This tool was useful years ago when everyone was implementing their own session management systems. These days most of these sub-systems are part of the core web frameworks and therefore already tested - we hope. That being said, there are still bugs to be found but this falls into the realm of security research.
We did run into a few roadblocks and as a result we were forced to carve features out from the final product. However, the decision is not final and maybe if we manage to convince the app reviewers that these features are vital to the users we may be able to bring them back soon. We are working on these very hard and also trying to find out other workarounds.
Yes of course. We had to remove the integration with the notification API and also remove the facilities which allow us to install the CA certificate smoothly into your device. The second was flagged as breaking a clause which states that all applications should be self-contained. Which in our opinion is understandable concern although the feature would have saved a lot of people an extra step to get the CA and other certificates in the correct place in order to ensure smooth communication.
If I can give any tips, whenever I'm questioning if a feature is going to get called out when I submit an app, I always fill that "info for reviewer" section with tons of stuff. Explanations, links to docs & legal to show that I'm not doing anything against the law/rules.
As an aside, IMO claiming that Charles isn't native is a little disingenuous. Yes it's built with Java, but I wouldn't dismiss it as non-native (unless you're using native in the purest of ways, meaning that its "natural" - e.g. Cocoa - to the system). I consider tools like Eclipse and IntelliJ "native" even though their UI may be poor compared to Xcode.