My gripes are (please take if you want it, criticism is a strange thing, I am slightly harsh and a bit subjective):

_update() falls after _draw(), and I'm not sure if that affects execution or not but in case it does, might wanna flip it around -- if the current position is 2 but it's showing 1, you might do something that's not very great. (Given how fast they both call, it's very minimal, but... just in case.)

Second, you have to be on the exact same line as the fruits to earn points. The Y-axis is disregarded, so you can be as far above it as you want and still earn points.

if x  == starx  then
score += 10
end

It's a better idea to give it a range, so that you don't have to match the X values.
Plus the fruit location prolly needs to be changed when you collect it.
And of course, Y needs to be taken into account.

You can give it a try yourself. Or just study this, but I recommend at least trying it on your own given what I've told you.

if ((x >= starx) and (x <= starx + 7)) and ((y >= stary) and (y <= stary + 7)) then

--[[
the above is:
(is x within the boundaries of the fruit?) and (is y within the boundaries of the fruit?)
the +7s are there to get the bottom corners of the sprites
i could've used abs() to use fancy absolute numbers but i'm too lazy right now
--]]

score += 10

-- then, we change the fruit location
starx = flr(rnd(120))
stary = flr(rnd(120))
-- and the fruit type
oby = flr(rnd(2)) + 4

-- note that the screen is 128 by 128, so you could have done flr(rnd(128))

end

Third... it's not even posted in the jam. Or at least not as far as I can tell. Unless you don't want to, which is absolutely fine. Jus letting you know.