What would be the best way to do this? I see the CCEaseSineInOut action but it doesn't look like that could be used to do this.

I need to move from one side of the screen to the other. The sprite should move in a sine-wave pattern across the screen.

I always like to have complete control over CCNode motion. I only use CCActions to do very basic things. While your case sounds simple enough to possibly do with CCActions, I will show you how to move a CCNode according to any function over time. You can also change scale, color, opacity, rotation, and even anchor point with the same technique.

@interface SomeLayer : CCLayer
{
    CCNode *nodeToMove;
    float t; // time elapsed
}
@end

@implementation SomeLayer

// Assumes nodeToMove has been created somewhere else
-(void)startAction
{
    t = 0;

    // updateNodeProperties: gets called at the framerate
    // The exact time between calls is passed to the selector
    [self schedule:@selector(updateNodeProperties:)];
}

-(void)updateNodeProperties:(ccTime)dt
{
    t += dt;

    // Option 1: Update properties "differentially"
    CGPoint velocity = ccp( Vx(t), Vy(t) ); // You have to provide Vx(t), and Vy(t)
    nodeToMove.position = ccpAdd(nodeToMove.position, ccpMult(velocity, dt));
    nodeToMove.rotation = ...
    nodeToMove.scale = ...
    ...

    // Option 2: Update properties non-differentially
    nodeToMove.position = ccp( x(t), y(t) ); // You have to provide x(t) and y(t)
    nodeToMove.rotation = ...
    nodeToMove.scale = ...
    ...

   // In either case, you may want to stop the action if some condition is met
   // i.e.)
   if(nodeToMove.position.x > [[CCDirector sharedDirector] winSize].width){
       [self unschedule:@selector(updateNodeProperties:)];
       // Perhaps you also want to call some other method now
       [self callToSomeMethod];
   }
}

@end

For your specific problem, you could use Option 2 with x(t) = k * t + c, and y(t) = A * sin(w * t) + d.

Math note #1: x(t) and y(t) are called position parameterizations. Vx(t) and Vy(t) are velocity parameterizations.

Math note #2: If you have studied calculus, it will be readily apparent that Option 2 prevents accumulation of positional errors over time (especially for low framerates). When possible, use Option 2. However, it is often easier to use Option 1 when accuracy is not a concern or when user input is actively changing the parameterizations.

There are many advantages to using CCActions. They handle calling other functions at specific times for you. They are kept track of so that you can easily pause them and restart them, or count them.

But when you really need to manage nodes generally, this is the way to do it. For complex or intricate formulas for position, for example, it is much easier to change the parameterizations than to figure out how to implement that parameterization in CCActions.