> On Apr 29, 2015, at 7:51 AM, Torsten Curdt wrote:
>
> Having the explicit __DATE__ in the binary as string makes it a little bit
> too easy to change.
If someone’s determined enough to patch the binary, there’s nothing you can do
about it. No matter how carefully you encode/hide the timestam
I run this script in the Run Script of the Build Phase:
infoplist="$BUILT_PRODUCTS_DIR/$INFOPLIST_PATH"
builddate=`date`
if [[ -n "$builddate" ]]; then
defaults write "${infoplist%.plist}" BuildDate "${builddate}"
fi
-rags
___
Cocoa-dev mailing l
Thanks for the code.
It's what I meant with "converting those into a timestamp at runtime isn't
ideal" though.
Having the explicit __DATE__ in the binary as string makes it a little bit
too easy to change.
I would like to use it for expiring beta releases.
cheers,
Torsten
On Wed, Apr 29, 2015
This is pretty much the same technique I've used to embed build information in
the app settings bundle.
-Daniel
> On Apr 29, 2015, at 6:04 AM, Damian Carrillo wrote:
>
> I have exposed build-time information to an application in the past. The
> approach I chose leveraged a Run Script build p
I’m not concerned with the time, but I get the build date as an NSDate with
this method:
- (NSDate*) buildDate
{
NSString* dateStr = [NSString stringWithUTF8String: __DATE__];
NSDateFormatter* dater = [[NSDateFormatter alloc] init];
NSLocale *enUSPOSIXLocale = [[NSLocale alloc]
initW
I have exposed build-time information to an application in the past. The
approach I chose leveraged a Run Script build phase that overwrote the contents
of a plist or a header file (I’ve used both). I created the initial file and
added it to git. Then, I ended up assuming that changes to the pli
I would like to embed the timestamp of the build into my executable.
I know there is __DATE__ and __TIME__ but converting those into a timestamp
at runtime isn't ideal.
So I guess I somehow need to make the output of date +%s available to the
preprocessor. But user defines allow only static value
