Codea 3.2.2 (225)

Codea 3.2.2 (224)

  • Big change to document undo: undo now happens per-tab and flipping between tabs will allow you to undo and redo changes specific to those tabs. Global changes, like deleting and inserting tabs, can still be undone until you make any further code edits
  • Fixes “Replace All” crash

Known issues

  • Search can sometimes leaves highlight in wrong place when editor is resized

Please let me know if you experience any problems with saving or undo. I’m hoping per-tab undo works a lot better, but it was a big architectural change and I may have overlooked some things in implementing this

@Simeon, I still have problem in putting my app to App Store.
As we discussed, Codea 2.x is using UIWebView which is no longer accepted by AppStore at all even for internal TestFlight. Until recently Apple allowed internal TestFlight but not external.
Codea 3.0 is not capable to generate archive required for submission to App Store.
Codea 3.2.1 is capable for making archive, however Apple requires explanation for use of ARKit and True Depth API in their review process.
However, since I don use those features, I am not able to EXPLAIN the reason for useage.
Finally, Codea 3.2.2 causes two failures in building process;

  1. RuntimeKit.h not found &
    2)failed to emit precompiled header '/Users/ishizuka/Library/Developer/Xcode/DerivedData//-dipfqylgerxmfjgiaglcmwlxv/Build/Intermediates.noindex/… for building header '/Users/…/-Bridging-Header.h
    Thus, currently I have no way to submit my app coded with Codea to App store.
    I wish if I can exclude ARKit and True Depth features in zipping project for Xcode.

@Makoto are you using any of Craft APIs in your app? Just thinking of how to remove ARKit references in the framework to allow you to upload

@Simeon Not at all. I am not using ARKit nor TrueDepth feature.
A project sipping option not to include ARKit nor TrueDepth woth Codea 3.2.1 is the most convenient. Please find the rejection message from Apple below:

Regarding Codea 3.2.2, Xcode generates space holder of frameworks but not actual framework folders which are generated in case of Codea 3.2.1 projects. The situation is similar to the Codea 3.0.1 with the info.plist edited to “3.2.1”.

–Rejection message from Apple ------------------------------
May?,2020 4:59
From: Apple
2. 1 Performance: App Completeness
2. 5 Performance: Software Requirements
Guideline 2.1 - Information Needed

We have started the review of your app, but we are not able to continue because we need additional information about your app.

Next Steps

To help us proceed with the review of your app, please provide detailed information to the following questions. The more information you can provide upfront, the sooner we can complete your review.

Please provide information on how to league your ARKit feature.
Once you reply to this message in Resolution Center with the requested information, we can proceed with your review.

Guideline 2.5.1 - Performance - Software Requirements

During review, we found that your app includes TrueDepth APIs. However, we were not able to locate any features in your app that use TrueDepth APIs.

Next Steps

If your app does not include any features that use TrueDepth APIs, please remove them from your app.

If your app does include features that use TrueDepth APIs, please reply to this message in Resolution Center to provide information on how to locate them.

@Makoto I will need to create a special build of the frameworks for you that excludes ARKit and the TrueDepth API use. I’m not sure of the best way to handle this, Xcode export has gotten a lot more complicated over the years due to privacy requirements and App Review

@Simeon could it be similar to the current xcode export, but you analyze the user code to see if there is a ‘scene’ line present, if there is it is a full export, otherwise ARKit and TrueDepth are excluded. Of course it is easy for me to say, but it might be a lot of work on your side. Some of my upcoming apps do not use craft, so i hope a solution can be found.

@piinthesky it actually requires that I pre-build libraries in different configurations (AR, no AR, no Face AR, no depth camera). Which is really tough. I’m building the 3.2.2 libraries without AR and depth camera functionality at the moment so @Makoto can submit with them


Can you please try deleting the .framework files from the Frameworks/ folder, changing libversion to 3.2.2 and rebuilding / resubmitting your binary to the App Store?

I have removed depth camera and AR support from the frameworks

OK. But the object of the procedure you are suggesting looks the project made by Codea 3.2.1. However since I upgraded to Codea 3.2.2, I have no capability to used Codea 3.2.1.
Thus, I made a new project with Codea 3.2.2. The zipped project has only a libversion file “3.2.2” under Frameworks folder. This time Xcode successfully build and archive the project and I could submit it to App Store. See what happens.

It looks Codea 3.2.2 is now working properly, the zipped project does not cause error in building process as I reported before.

Yeah you can use your previously exported project if you modify the libversion file to contain 3.2.2. But re-exporting is also an option

@Simeon if i do a new export with Codea 3.2.2 and want to use AR support/depth camera i guess i just need to change the libversion to 3.2.1?

@piinthesky yes (for now). At the moment AR is tied into face tracking which is an issue, because including face tracking can get your app rejected unless it specifically uses it

@Simeon, the xcode export with auto assets still forgets the ‘blocks’ and ‘hidden’ assets. I notice the auto assets seems to also bundle assets that are commented out in the code.

Actually for what i am doing (with lots of 3d models) i hit the app store limit (200 Mb) on the app size! So reducing to a minimum the download size can be relevant. I may need to implement downloading of my assets via https-if that is possible for app store apps.

@Simeon, Finally, I got approval for beta testing. It looks Apple has no issues on the project coded with Codea 3.2.2. Thank you!

@Simeon MOVING no longer shows in autocomplete. I haven’t check what else is missing.

@dave1707 yes, MOVING has now become CHANGED, but the MOVING global still works for backwards compatibility

@Simeon I looked at the touched function in the reference, and sure enough, CHANGED is there. I guess I’ll have to remember to start using that.

@Simeon There’s a slight problem in the touched function. The id value is different if you print touch and print The difference is 4294967296 which is 2^32. Version 3.2.2 (225)

function touched(touch)
    if touch.state==BEGAN then

@Simeon Here’s something else I found with touch. I don’t know if it’s related to the above problem. The below code is the Multi Touch example with the displayMode(FULLSCREEN) added. If you just touch and hold the screen (without moving your finger) a circle shows, which it should. If you do the same thing within about 50 pixels or less of the left side of the screen, you don’t get a circle. The for loop with touches in draw doesn’t find anything in the table touches and doesn’t draw the circle.

PS. If you get close to any edge, you don’t get the circle.

PS. Something else. If I constantly tap the screen barely lifting my finger from the screen as I move my finger, the circle will change color but it doesn’t change position. I can get my finger about an inch or so away from the circle if I do it just right.


function setup()
    print("This example tracks multiple touches and colors them based on their ID")
    -- keep track of our touches in this table
    touches = {}

-- This function gets called whenever a touch
--  begins or changes state
function touched(touch)
    if touch.state == ENDED or touch.state == CANCELLED then
        -- When any touch ends, remove it from
        --  our table
        touches[] = nil
        -- If the touch is in any other state 
        --  (such as BEGAN) we add it to our
        --  table
        touches[] = touch

function draw()
    background(0, 0, 0, 255)
    for k,touch in pairs(touches) do

        -- Use the touch id as the random seed

        -- This ensures the same fill color is used for the same id
        -- Draw ellipse at touch position
        ellipse(touch.pos.x, touch.pos.y, 100, 100)

@dave1707 interesting, the ID not printing correctly may relate to @RonJeffries problem, as the ID is based on the memory address

On the second issue I have a feeling it’s due to the iOS system gestures interfering with Codea touches. This is probably something we could disable in the FULLSCREEN_* modes. Will test